Boost logo

Boost :

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-11-25 11:46:46

Hu Xinwei wrote:

>> It is surprisingly difficult to portably tell this thread that it
>> should terminat itself.
> Well, the portable method I know is like this:
> listen thread:
> for (;;) {
> fd = accept();
> if(server_should_shutdown) {
> //do something here then exit
> }
> //process fd here
> }
> helper thread:
> set_server_should_shutdown();
> connect_server_itself();
> So no interrupt is needed here.

Yep, that's the only portable way I know of, too. But you would be
surprised how many times you find this one:

helper thread:

And then people are wondering why it works on some platforms and
deadlocks on others. I think the socket library should provide a
better solution in encapsulating the above code.

>>>> - How do you wait for more than just socket events? Thread
>>>> conditions, window messages, ...
>>> I think that is not a problem too. We at such a condition,
>>> should have 2 threads, one to block on socket, and another
>>> handles all other messages from os, other processes...... If
>>> you are really intersted in the thread conditions, you have to
>>> poll them by yourself, because there is no such a generic
>>> mechanism on every platform
>> And that's one of the main reasons why we should provide one. At
>> least a possible interaction with conditions from boost threads.
>>> and it is rearly used.
>> What makes you think so? It's quite important in server
>> programming.
> I prefer to make all sockets work in blocking mode, when I use
> threading-model. Reactor or Proactor are other problems. ;-)
>>> IMO, thread model is used to simplify your design. One thread
>>> should take one resposibility and one only.
>> Say you have a thread responsible for communication with some
>> clients. You have to have a way to tell this thread that there is
>> new data available for the client. At the same time the thread
>> has to wait for new data coming in from the client. How do you
>> solve this?
> It depends.
> For example, a tcpforwarder. I'll create 2 threads, one for server
> to client, another for client to server. For another example, a
> file-sender. I'll block on send, no matter if there're new data
> from other threads. One more example, a file-reciever. I'll block
> recv then block on save.
> In fact, all works performed in one thread should be syncronized.
> So, I think, a well designed server can avoid this problem.

AFAICT, you are assuming a one to one relationship between threads an
clients? Is this true?


Boost list run by bdawes at, gregod at, cpdaniel at, john at