>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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
