Hi...
I am trying to write a multi-threaded echo server program. But facing
some problem with it...
First of all, I am sorry to remind you that your question is user space
related issue, however personally I try to reply since it has something
to do in kernel space. So here we go
But the problem is that, only one thread was doing all the work
(handling all the connections), other threads are just blocking in
select() system call even when all of them have the same information.
But, I am not able to understand why other threads select() didn't get
any response when the file descriptors change their status?
Reading above, I think it is the glibc that defines this behaviour. It's
delivering the "wake up" signal to the first process that does the
select on distinct fd or set of fd. Personally, I think it is legal to
for multiple processes to select() on same set of fd, creating a linked
list consisting of sleeping processes waiting for changed status. If we
assume waking up is done using exclusive style (just wakes one and
finish), then it's easy to understand that the head of list will always
get the turn.
What you should do is probably dig glibc source and prove if it indeed
queue the process in exclusive (this is what I remember) mode.
Isn't this nice if either the thread library or the OS balance the work
between different threads especially when all of them are waiting on
similar condition?
I suggest another way. Main thread still does select() on that set of
fd, but the worker threads don't. Put each worker threads to sleep. Once
main thread detect fd status change, find out which fd it is, wake up
(by sending signal) one idle worker, and pass it the fd that it should
take care. You may use any kind of IPC to pass that info.
The trick here is, to maintain the busy status bits of each worker and
intelligently assign the arriving jobs. But as a start, you can simply
do in round robin style.
I hope this idea helps you.
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
