Re: Best Practice For Forcing A Thread To Unblock Itself

Le Chaud Lapin wrote:
> Jochen Kalmbach [MVP] wrote:
>> Hi Le!
> Hi Jochen.
>
>> SetEvent ?
>> And thread B should always wait with "WaitForMultipleObjects"...
>
> There lies the problem. I was going to insist that thread B always
> uses WaitForMultipleObjects, but the problem still remains with the
> select() function in sockets. Right now I am having thread A close
> the socket that B is select()'ing on to force B to unblock.
You should use the WSA* "extended" winsock API instead of the Berkley style
API. This would allow you to use WSAWaitForMultipleEvents, passing to it
both the socket and a "signal to exit" event.

> Guess I will check to
> see what POSIX offers like WaitForMultipleObjects.
Nothing : Under POSIX, you would use signals to, well to *signal* the thread
to stop ;-). Note that you can also use a similar mechanism in Windows, with
a user-mode APC (see QueueUserAPC). This needs your waiting thread to be in
an alertable wait state, but this is no problem with
WSAWaitForMultipleEvents.

Still another option would be to call WSACancelBlockingCall on (one of) the
socket(s) in thread A and to check the return value of select in thread B.

Anyway, generally speaking, when complex synchronisation take place, it is
generally a bad idea to try to map the Unix style idioms to Win32 : they
support different mechanisms, and you should try to take advantage of those
mechanisms : In one hand, Unix has signals (which you can more or less
emulate with APC, but in much more specific ad limited cases). On the other
hand, Win32 has non blocking IO, which should be the preferred choice when
having high-performance or complex synchronisation needs.

> -Le Chaud Lapin-
Ah bon??? Sacrés gaulois ;-)

Arnaud
MVP - VC


.

Relevant Pages

  • [UNIX] OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals
    ... OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals ... Which process is notified depends on the ownership of the file descriptor. ... calls the socket function in the case of sockets). ...
    (Securiteam)
  • OpenBSD bug
    ... default behaviour in OpenBSD is to ignore these signals, ... arrives to an specific file descriptor, ... calls the socket function in the case of sockets). ...
    (Bugtraq)
  • Re: Humans cant produce informationally complex DNA?
    ... humans use to produce these types of radio signals. ... adequately detect design in nature. ... They don't really have the mechanisms, ... We have a human mechanism - just like SETI has. ...
    (talk.origins)
  • Re: Realtime SIGIO signals questions (linux)
    ... i checked the socket code, and it does remove the process from the list when close is called, so that's not something u should be worried about. ... >> causing a SIGIO to be queued. ... >> same descriptor as the one I just closed. ... >> realtime signals a go. ...
    (comp.unix.programmer)
  • Re: Humans cant produce informationally complex DNA?
    ... The mechanism could be very similar to the mechanisms used by humans ... where's the physical evidence of this? ... humans use to produce these types of radio signals. ... Seti scientists have the mechanisms, ...
    (talk.origins)