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

John Miller millejoh at mac.com
Sat Apr 18 07:12:57 PDT 2009

Even better news is that the changes seem to have fixed the problem I  
was seeing.  Slime/swank works like a charm.  I get an error caling  
(xlib:open-display), but it seems to be an issue with X, not CCL.

Thank you!

On Apr 18, 2009, at 5:07 AM, Gary Byers wrote:

> The good news is that I checked in some changes (to windows-calls.c,  
> in
> both 1.3 and the trunk) that're intended to handle the case where
> WriteFile returns ERROR_IO_PENDING.
> The bad news is that none of the (real or virtual) Win32 machines that
> I have access to seems to ever return ERROR_IO_PENDING from calls
> to WriteFile, so I haven't been able to test this (beyond convincing
> myself that the changes don't seem to break anything in the case
> where the WriteFile call completes synchronously.)
> If John or anyone else who gets the spurious "error 22" trying to
> force output to a socket could do an "svn update" and a kernel
> rebuild and let us know whether this fixes the problem, that'd
> be great.
> On Fri, 17 Apr 2009, Gary Byers wrote:
>> On Fri, 17 Apr 2009, John Miller wrote:
>>> 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.
>> The file handle that we're dealing with is a socket (not created by  
>> lisp_open),
>> and it seems that sockets have the FILE_FLAG_OVERLAPPED bit set;  
>> doing a
>> read on a socket has to go through the whole song-and-dance of  
>> dealing
>> with overlapped I/O.
>> Writing to a socket (or, more generally, writing to any file  
>> handle) -might-
>> not complete synchronously, but I don't think that I'd seen this  
>> happen
>> and the code in lisp_write doesn't deal with it at all (and  
>> completely
>> misinterprets the ERROR_IO_PENDING return value as an error.)  It  
>> seems
>> like lisp_write() needs to go through a song-and-dance somewhat like
>> lisp_read() does.
>>> I wonder what would happen if the function just ignores this error  
>>> (err.. notification)...
>> My understanding is that the write has been initiated (or at least
>> scheduled), but I don't think that we can tell whether or not it
>> completed or whether all of the bytes that we wanted to write have
>> been written without waiting around (waiting for the event handle
>> in the overlapped structure to be signaled, checking for other
>> errors, etc.)
>> I have a dim and perhaps incorrect memory that that code had been
>> written at one point (we're still setting up an event handle), but  
>> was
>> removed because it didn't seem necessary.  It may be the case that  
>> the
>> decision of whether or not to complete socket writes synchronously or
>> not is made or influenced by the NIC driver, and that we just haven't
>> seen this so far because most drivers usually decide that there's no
>> good reason to return ERROR_IO_PENDING.
>>> 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.
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list