________________________________
>> I've been reading your mailing lists a long time ago and following
>> all threads about multithreaded questions like having an acceptor
>> thread which delivers fd's to another threads to process
>> request. Basically my project design will be based on a pool of
>> threads waiting to events on fd's 'listened' on one or more acceptor
>> threads. I found this explanation posted on your home page
>> (http://monkeymail.org/archives/libevent-users/2007-January/000450.html)
>> about multithreaded use of libevent, but pipe() is not the way I
>> though in passing messages from one thread to another, even the fd's
>> from acceptors to the thread-pool.
>>
>> Do you think that in the next release 1.5/2.0 this behavior should
>> be well implemented, instead of using libev features any time soon?
>_Which_ behavior exactly? I can't tell for sure from your write-up
>what feature it is that you want. Are you talking about the libev "
> - fast intra-thread communication between multiple
> event loops (with optional fast linux eventfd backend).
>" thing? Looking at the source, it seems that it does use "pipe"
>everywhere except on Linux. Is it the _abstraction_ here that you had
>in mind; the ability to wake up a looping event base from another
>thread in a safe, generic, and platform-optimized way? Something like
>that would indeed be cool for 2.0.
>Heck, I think I'll go hack up the basic implementation now.
>yrs,
>--
>Nick
Hi Nick, thanks for replying!
Since I'm too new in async event notification world, all I'm doing right now is
read and study all possible technologies and paradigms, and trying
understanding them.
I know the best way to do that is start hacking on them, but since my project
is still under designing phase, hence my doubts. I do think this is the right
abstraction I need to my project, and it would be very nice to have this on
1.5/2.0 release :)
But as writing this mail, another doubt emerged. Let's suppose I have one
acceptor thread with it's event base loops waiting on network events to listen
and then forward them to a thread pool abstraction layer. If I did it using a
fifo buffer (i.e. a fifo linked list) passing it's fd's to the thread pool,
this could be possible with each thread having it's event loop and thus not
receiving spurious events from fd's each are handled on the others threads from
the pool? Or maybe the best way is having one event loop base to all thread
pool, each thread receiving it's fd's events without spurious wakeups? Is this
abstraction your talking about on the next release (1.5/2.0)?
Andd the last one, with the 'linux eventfd backend', could this be
accomplished? I mean, my acceptor thread could just be 'throwing' new events to
the thread pool with this eventfd thing?
Thanks again for all you attention and patience.
Best regards,
Raine
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
