[Openmcl-devel] wx86cl-Windows XP SP3 32bit-socket error #22 during write

[Raymond Wiker]

On Apr 17, 2009, at 08:44 , Gary Byers wrote:

>
>
> On Thu, 16 Apr 2009, John Miller wrote:
>
>>
>> On Apr 15, 2009, at 2:36 PM, Gary Byers wrote:
>>
>>>
>>>
>>> On Wed, 15 Apr 2009, John Miller wrote:
>>>
>>>> I am running CCL 1.3-r1195 (WindowsX8632) and getting the below
>>>> "(error #22) during write" when trying to connect to the Xming
>>>> server (or is that client? never could get that straight) on my
>>>> Windows XP, SP 3 machine.  I also get the same error when I try to
>>>> connect to swank from Emacs using slime.
>>>
>>>> I have another Windows XP machine that runs as a virtual machine
>>>> under parallels and I do not have any problems running slime+swank
>>>> on ccl on that machine (haven't tried clx, though).  I am stymied-
>>>> which is admittedly a pretty easy thing to do- but I was wondering
>>>> if anyone could provide insight into what an "(error #22) during
>>>> write" means.
>>>
>>> It means "The device doesn't recognize the command."  (I suppose  
>>> that
>>> you'll want to know what that means now. I don't know yet.)
>>>
>>> On the machine that has problems, does networking generally work ?
>>> E.g., is some network interface configured ? One would think that
>>> that wouldn't matter much, since you're just trying to connect to
>>> the loopback address, but this is Windows ...
>>>
>>
>> I also should add that I rebooted my Win machine in diagnostic  
>> mode, which
>> disables all the cruft my employer has placed on this machine, and  
>> I still
>> get the socket error.  I installed SBCL 1.0.22 and it runs the  
>> slime/swank
>> combo just fine.  Not sure what else I can check, and I believe I  
>> am the only
>> unfortunate slob in the CCL universe with this problem, so I have a  
>> feeling
>> this one is going to remain a mystery.
>>
>> Thanks anyway...
>
>
> Confusingly, there are a couple of different sets of error numbers
> that can be relevant under Windows:
>
>  - some functions return (perhaps indirectly, by setting the "errno"
>    thread-local variable) a POSIX error number to indicate an error.
>
>  - many functions return (in another thread-local variable that can
>    be accessed via #_GetLastError) a Windows error code.
>
> The actual numbers can conflict, but conflicting POSIX and Windows
> error numbers generally have nothing to do with each other.
>
> In the case where you get an "error 22" during FD-STREAM-FORCE-OUTPUT,
> we're interpreting the "22" as a Windows error number:
>
> ? (ccl::%windows-error-string 22)
> "The device does not recognize the command. "
>
> but the function that failed actually returns a POSIX error number:
>
> ? (ccl::%strerror 22)
> "Invalid argument"
>
> I don't know which of these is more generic and less helpful, but
> I actually think that the POSIX interpretation may be very slightly
> helpful.  The function that generates the error is a call to WriteFile
> in the function lisp_write (in ccl/lisp-kernel/windows-calls.c):
>
>   if (WriteFile(hfile, buf, count, &nwritten, &overlapped)) {
>     return nwritten;
>   }
>
>   err = GetLastError();
>   _dosmaperr(err);         /* map Windows error to POSIX error, set  
> errno */
>   return -1;
>
> So, the call to WriteFile is returning a Windows error number that  
> gets
> mapped to EINVAL (=22).  If you look at the function _dosmaperr (in  
> that
> same C source file), you'll see that a small number of Windows errors
> are mapped to specific POSIX errors and anything not enumerated gets
> mapped to EINVAL: we don't know with any confidence what WriteFile was
> really complaining about.

I seem to recall that Windows, unlike Unix and Unix-a-likes, does not  
allow read()/write() to be used on both file descriptors and socket  
descriptors; for the latter, recv()/send() should be used. "Invalid  
argument" may well be the error code I got when I got hit by this, a  
good few years back.

Not sure if this is relevant, as you seem to be using Win32 calls, and  
not Posix ones - but then again, you do refer to  Posix error codes :-)

The variation in behaviour on using Slime might be due to Slime  
version / communication setup...