On Mon, Jul 16, 2012 at 08:48:01AM +0800, debuguo <waterawo...@gmail.com> wrote:
> In accept ev_loop I put a pair of ev_io and ev_timer to monitor the file
> descriptor returned from socket, once the ev_io get EV_READ event, the
> server accept the connect and get the file descriptor, then dispatch it to
> one read/write ev_loop. the point is how to do the dispatching.
In most cases, queuing it somewhere and signalling an async watcher to
dequeue it is the best solution in your design, assuming you use multiple
threads,
> mentioned before in "*a demo code considering if ev_async event missing*",
> Not every ev_async_send can invoke the ev_loop to one callback when
> ev_async_send called very frequently.
No ev_async_send can every invoke the callback, all it can do is mark the
watcher as pending eventually. Every ev_async_send will do that, none will be
missed, but multiple calls might result in fewer calls of the callback.
The frequency of invocation is only peripherally related to that.
> so I used a pthread_cond_t to
> pthread_cond_wait() the last ev_async_send() invoke into the callback,
Hmm, how do you know that a specific call is the "last one" (assuming you
mena the last one before the loop invokes the callback)? To me, at least that
sounds difficult.
Also, why do you feel the need to actually wait? If you can wait for the
loop to respond, does it sitll make sense to have a separate thread for
accepting?
Keep also in mind that unless you have one thread per cpu or so, going
to and from your accept thread requires two extra thread switches, which
aren't cheap.
> pthread_cond_signal() the pthread_cond_t in the async callback. I wonder if
> this is a good policy to dispatch the file descriptor, and if there is a
> better one.
It of course depends on your problem, but queuing the file descriptor
would probably result in the lowest latency, since nobody has to wait.
> I used ev_async to exit ev_loops, when exit, in the async callback, just
> ev_TYPE_stop any watchers, then ev_break.
If you are not going to reuse the loops or the watchers after stoping, you
can just destroy the loops btw.
> It seems running well. Is there any improper thing in my description?
Well, condvars are rather scary beasts (for example many people forget
to check the condition when e.g. pthread_cond_timedwait returns with an
error), so I'd say apart from possible complexity there, it will probably
do what you want.
> I just wonder if there is any better ways to dispatch/notify from one
> ev_loop to the other, and if there is any better solutions to exit ev_loop.
There might be "better" ways for your taste or your speciifc problem, but
there is no unconditional better way to do it.
In the end, if you want to wake up the loop, you have to use an async
watcher *somewhere*.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
