On 4/12/07, Adam Chou <[EMAIL PROTECTED]> wrote:
So i'm using libevent thus far to handle incoming requests and new
connections. When new connections come in or data on an already connected
socket come in, i'd like to pass off the connection to a thread to let the
thread handle the data transactions and processing.
I'm sorry, but why would you want to do something like that?
Just for the overhead of context switching? (sorry, couldn't resist)
I'm doing this by
putting a socket id on a ring buffer and having the worker threads pull from
the ring buffer as new tasks become available. The problem with this (or so
it seems to me) is that I can't add the event back to the event handler
until the worker thread has finished reading all the available data from the
socket or else libevent will keep signaling that there is data waiting to be
read and flood my ring buffer with requests.
You're not using libevents' bufferevents, are you?
If it isn't apparent already, I
can't add the event in the worker threads because libevent (as i understand
it) isn't thread safe like that. So how do I go about implementing a system
that will allow worker threads to handle a connection and have a master
libevent thread handle events?
I think you should re-think your application design.
1. If the processing time of each client request is relatively short,
you don't need threads. Use libevent and bufferevents. Just process
every request directly in the input callback. You don't need to think
about semaphores, mutexes and such horror.
2. If the processing of each client request takes long time and might
block other requests, try to break it up into chunks. After each chunk
you schedule another one (with a timer of 0 seconds) and go back to
the event loop.
I've implemented this successfully for a request that needed a full
filesystem directory tree traversal. Each chunk/iteration would
traverse 5 directories, then schedule another chunk and return to the
event loop. Back in the event loop I would then either process any
outstanding socket event, or go back to the directory traversal
request.
3. Have you considered using a fork based approach? If the processing
of each client is independent of each other, you don't need threads.
4. Finally, if nothing of the above is possible, why use libevent at
all? Use blocking sockets and a simple accept() loop that spawns off
threads.
Additionally, I'd like to also be able to
have the worker threads somehow close the connection in the instance that
the client gets disconnected between the time the client sends in a request
and the time that the worker picks up the request and processes it. Thanks
in advance for any help.
I'm sorry if the above seems harsh, but I really don't see the point
in implementing a multi-threaded libevent server.
Oh, additionally, It seems like once an event handler gets an event, I don't
need to event_del() the event since its already removed from the event stack
but i just wanted to clarify that if someone could answer this question for
me. Thanks
I guess that depends on if you specify EV_PERSIST or not. But I let
others elaborate on that.
-martin
_______________________________________________
Libevent-users mailing list
[EMAIL PROTECTED]
http://monkey.org/mailman/listinfo/libevent-users
