Re: To thread or not to thread ?
"Le Chaud Lapin" <email@example.com> wrote in message
Yechezkel Mett wrote:
You use a "shutdown" event, and every blocking operation in the thread
uses WaitForMultipleObjects with the shutdown event as one of the
That sounded like a good idea, but how will it solve THE problem of a
blocking socket read, for example, since you can't wait on the read
and an event both with WaitForMultipleObjects?
You have to use what Microsoft calls overlapped I/O, and you have to
use the Windows-specific version of Berkeley's recv function, WSARecv
Essentially, you invoke a function to declare to to the TCP/IP stack
that you are ready to read data from the socket, and the function
returns a code telling you, "Ok, I'm trying to read now, blocking,
waiting for data, but do not touch the buffer you gave me". Then when
it actually puts data in the buffer (or is simply ready to put data
somewhere), it either calls a routine that you supplied in the read
call, or signals an event whose handle you supplied in the read call.
That event can be one of many arguments for WaitForMultipleObjects. [I
know you know most of this, I'm writing for edification of other
It it a mess? Yes. Do we have an alternative? No, it is what
thousands of programmers deal with every day.
This is one of those areas where truth of form begins to grind against
our models slowly, until the realization of systems based on that model
becomes so ugly that we are forced to redress. In this case, we are
forced to see that, in a multi-threaded applications, there should
exist a portable means of waiting for multiple synchronization triggers
at strategic locations in code. and any blocking function should
provide a portable mechanism to break in an orderly fashion.
-Le Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]