Boost logo

Boost :

From: Hu Xinwei (huxw_at_[hidden])
Date: 2002-11-25 11:45:29

>Hu Xinwei wrote:

>> - How to interupt a thread waiting on some socket event
>> (synchronous and asynchronous) from another thread?
> IMHO, I dont think such a mechanism is needed.

>A typical example: You have a thread that implements a synchronous
>listener like this:


>while (true)
> fd = accept();
> // add fd to some connection list

>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();
      //do something here then exit
   //process fd here

 helper thread:
 So no interrupt is needed here.
>>> - 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.


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