[darcs-users] Unexpected wait return code

Alexander Staubo alex at byzantine.no
Sun Nov 14 00:07:21 UTC 2004


You can view the source in question here:

 
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/win32/AsyncIO.c?rev=1.5.2.2;content-type=text%2Fplain

It's Haskell's Win32 implementation of asynchronous I/O. Based on the 
logic, it looks like awaitRequests() is being called either before 
startupAsyncIO(), or, more likely, after shutdownAsyncIO().

If you can recompile GHC on Windows, try adding this after the 
"awaitResuts: unexpected wait return code" error fprintf() call:

   fprintf(stderr, "GetLastError %lu\n", GetLastError());

It should give us more information.

Alexander

Alexander Staubo wrote:
> David Roundy wrote:
> 
>> On Wed, Nov 10, 2004 at 11:20:35PM +1100, Robert Leftwich wrote:
>>
>>> I'm running Darcs 1.0.0 on W2000 and I occasionally get the following 
>>> error when issuing commands (whatsnew, pull, record, etc) :
>>>
>>>    awaitRequests: unexpected wait return code 4294967295
>>>
>>> Google-ing turns up one email on the Haskell list with a similar 
>>> problem back in March, but no-one answered it.
>>>
>>> It doesn't appear to stop anything from working, but should I be 
>>> concerned?
>>
>>
>> Actually, I've seen this message myself, helping a friend set up darcs on
>> windows, and am curious as to what the deal is.
>>
>> Do any of the windows developers have an idea what this is? I certainly
>> don't.  I *can* confirm that darcs never calls awaitRequests directly, so
>> probably this is something internal to the ghc RTS or to the standard
>> libraries...
> 
> 
> It's a return code from the "wait for object" family of API calls, which 
> includes WaitForSingleObject() and WaitForMultipleObjects(), which are 
> roughly Win32's counterparts to select() -- they block until one or more 
> objects are signaled. Signaling happens for synchronization primitives 
> (mutexes, semaphores, etc.), threads, processes, async I/O operations 
> and a whole bunch of other Windows objects.
> 
> In this case it means WAIT_FAILED, which means that the function failed 
> in an unexpected way; the real error code can be read with 
> GetLastError() (Win32's version of errno). Since Haskell does not call 
> this function, it's hard to know what has happened. Note that when the 
> wait times out, or the object being waited for is orphaned by its parent 
> thread, the function should return different error codes, not WAIT_FAILED.
> 
> Looks like it could have something to do with either sockets or 
> asynchronous I/O:
> 
>   http://www.mail-archive.com/haskell@haskell.org/msg14662.html
> 
>   http://www.google.com/search?q=haskell++awaitRequests
> 
>>> PS I use a dual CPU machine and I'm curious if Darcs can take 
>>> advantage of this setup?
>>
>>
>> Alas, no.  Well, to a very slight extent.  Compressing and decompressing
>> files is done in a separate thread, so that could happen in parallel with
>> parsing, but this is so fast that it's not really worth it.  It's done 
>> in a
>> separate thread for other reasons than speed.
> 
> 
> I have a Linux SMP box, and I recently monitored the CPU usage while 
> doing some Darcs stress testing. From the output I can tell you that 
> Darcs definitely only ever uses one processor on "record", "whatsnew" 
> and "changes". No idea about other commands.
> 
> Alexander.
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://www.abridgegame.org/mailman/listinfo/darcs-users





More information about the darcs-users mailing list