[darcs-users] Unexpected wait return code

Alexander Staubo alex at byzantine.no
Sat Nov 13 23:58:36 UTC 2004

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:



>>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.


More information about the darcs-users mailing list