On Tue, Mar 24, 2009 at 1:41 AM, Rafael Sevilla <[email protected]> wrote:
> Well, that's exactly the architecture that I was describing. Thank you
> very much for spelling it out very clearly for everyone's edification.
no problem dude...
> 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.
dean made some good points with his post (nice to see you posting
again dean).. ill add more to it...
actually... pipe is more efficient and reliable than message queue and
shared memory in a busy inter-process communication... the problem
with message queue and shared memory is that you can only put a single
message at a time... unlike with pipe because it is one type of a
file... you can write more message into it...
in your current design.. when your acceptor keeps busy accepting
incoming requests while your worker is either sleeping or doing
something... your acceptor waits from your workers to fetch the
message either you use message queue or shared memory before it puts
another message into it and the backlog of incoming request keeps on
growing... thus preventing your server scalable.. you can make some
workaround but the code complexity requires cost.. thus another
hindrance....
> 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,
Unix is not an object-oriented and not totally event driven
architecture operating system when they first design...
> and if I'm not mistaken,
> this is also possible with kqueue on the BSD kernels.
sorry it is not possible... kqueue has limited events you can hook up..
> 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.
epoll is similar to kqueue...
> 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.
in your main thread.. the return filedescriptor of listen(2) function
is used by each of your workers and acts as an acceptor..
so instead the main thread is doing the acceptor.. each thread/worker
is now the acceptor referencing to the same filedescriptor that
listen(2) created...
take note that.. all your workers/acceptors are now referrencing to
the same filedescriptor.. when that filedescriptor is ready for an
i/o.. all your workers are awaken.. this is popularly known as the
thundering herd problem... the solution for this is to put exclusive
lock so that one thread/worker is acting as acceptor at a time...
sample code goes like this..
void *thread_or_worker_main(void) {
for ( ; ; ) {
pthread_mutex_lock();
acceptfd = accept(listenfd);
pthread_mutex_unlock();
do_something_with_this(acceptfd);
close(fd);
}
}
int listenfd;
int main(void) {
listenfd = listen();
create_thread_for_N_workers();
}
the ball is now up to your creativity how you use this technique to
your own advantage...
fooler.
> --
> You are still innocent until proven guilty. What has changed is
> what they do to innocent people.
>
+ first they rape her.. now they made her as a prostitute.. (what our
government done to nicole)
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
