From:	cgf AT cygnus DOT com (Christopher Faylor)
Subject:	Re: asynchronous socket operations (fwd)
7 May 1998 12:17:25 -0700 :
Message-ID:	<199805071855.OAA24308.cygnus.cygwin32.developers@kramden.cygnus.com>
To:	cgf AT cygnus DOT com, newsham AT lava DOT net
Cc:	cygwin32-developers AT cygnus DOT com

>> >So this seems workable.  Do I have this all right so far?  Questions --
>> >does cygwin already have a window handle that we can use for messaging
>> >(even when the process is a DETACHED_PROCESS)?  Is it worth the extra
>> >complexity in the signal code to check for wakeups (probably not that
>> >complex, extra messages on the queue probably don't hurt us)?
>> 
>> I'm not sure that you'd have to get signals involved int this.  It sounds
>> like most of this could be handled with Windows Events.  There
>> is already a SIGIO signal that is being handled for async socket I/O.
>> Is that not operating correctly?
>
>The reason I think we need to involve signal code is this:  We have
>to simulate a blocking operation without blocking out signals.  The
>only blocking operation that WSAAsyncSelect offers is to wait for
>a message (as far as I know -- I'm no win32 expert).  This operation
>does not have a timeout and does not allow waiting on other events.
>So to interrupt this blocking call when a signal needs to be delivered,
>the signal code would have to send a message to the queue.  Otherwise
>the wait-for-message primitive will not unblock and signals will not
>be delivered while a blocking operation is in progress.  This is the
>whole problem I am trying to solve (signals and blocking operations).

Ok.  I've done a little more research.  It looks like we'd want to
do something like:

WSAAsyncSelect (s, gethwnd (), WM_WHATEVER, mask);

HANDLE got_something = CreateEvent (NULL, FALSE, FALSE, NULL);
int waitfor[2] = {signal_arrived, got_something};

switch (WaitForMultipleObjects (2, waitfor, INFINITE))
  {
    switch WAIT_OBJECT_0:
	set_errno (EINTR);
	return -1;
    switch WAIT_OBJECT_0 + 1:
	/* something available on the socket */
	return 0;
    default:
	/* error */
   }

In the WndProc, there will be code to raise the got_something event
when a WM_WHATEVER arrives.

This is, of course, a very crude approximation of what can be done.
It doesn't involve any changes to the signal handling code, though.

Is that close or have I missed something?

cgf

- Raw text -