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:
   set_server_should_shutdown();
   close_server_fd();

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?

Markus


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk