[boost] Re: Sockets

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