[boost] Re: Sockets

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:

>bind();
>listen();

>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();
   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.
>>> - 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. 

>Markus