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

[John Miller]

Gary,

Well, I modified  _dosmaperr to return the error value it is passed if it cannot find a corresponding POSIX error.  Now it is returning error 997, which according to %windows-error-string is "Overlapped I/O operation is in progress  According to the MSDN (http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx) it is more of a notification than an error, signaling that WriteFile returned before the write operation completed.  I found another web page (http://www.microgate.com/techcenter/htmlhelp/html/hdlc5nzi.htm) that talks a little bit about how to handle async communication.  It makes the point that if this ERROR_IO_PENDING is returned one should take care not to make the same WriteFile (which must mean calling WriteFile with the same OVERLAPPED data) call until the communication is complete.

What doesn't make sense is that it looks like the function lisp_open calls CreateFile without the FILE_FLAG_OVERLAPPED flag set, so the communication should by synchronous.  I am not sure why on my machine WriteFile seems to think it is writing to an asynchronous handle.

I wonder what would happen if the function just ignores this error (err.. notification)...

Regards,
John



On Friday, April 17, 2009, at 01:44AM, "Gary Byers" <gb at clozure.com> 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.
>
>
>