Well, that's exactly the architecture that I was describing. Thank you very much for spelling it out very clearly for everyone's edification. What I have been thinking of is that using pipes for communication may be less efficient than using traditional IPC primitives such as a message queue or shared memory protected by mutexes/semaphores. I wonder why there isn't a select-like system call that allows one to block until a set of file descriptors and semaphore/mutex/message queues becomes available for use. I believe Windows has a WaitForMultipleObjects call that can do this, and if I'm not mistaken, this is also possible with kqueue on the BSD kernels. Linux doesn't seem to have a system call that can do something equivalent, although I've been seeing stuff like kevents that don't seem to have caught on in the main line of kernel development.
Well, my other question has to do with other idioms for making hybrid servers that use both threads and events. You mentioned a per-thread accept(2), I'm not sure how that might work. You mentioned a prethreaded server with per-thread accept(2) idiom. I suppose what this means is that the main thread listens for connections on the server port using a select/poll/epoll or whatnot, and then signals a worker thread from the thread pool somehow to do an accept on the socket for the server port itself, rather than the main thread doing the accept. The main thread would signal the worker thread to do the accept instead. The advantages of doing this over the main thread accept(2) idiom aren't exactly clear to me. -- You are still innocent until proven guilty. What has changed is what they do to innocent people. http://stormwyrm.blogspot.com
signature.asc
Description: PGP signature
_________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
