I think it is safe to use ev_async_send. It is possible that multiple ev_async_send are merged and the callback only called once. Since you use a queue to hold all accepted connections, it is not a problem(so you cannot avoid queue).
I think it is not safe to call ev_io_start with event loop which is used in worker thread in listen thread. ev_async_send can be used as you said. I think use pipe to send socket fd is good, because this can avoid the queue. memcached also use a queue to hold connections, very similar to your approach, but it use a pipe to notify worker threads - just send single char. I think send the socket fd directly would be better. 已从三星手机发送Chris Herssens <[email protected]> 写道：Thanks for the example. I see that you use a pipe for notifying the worker thread that there is a new connection. I don't to this in my code but I use ev_async_send() for notifying the worker thread ( see attachment files for the worker thread notification) My implementation is done as follows 1. each worker thread contains a lock free queue and has an ev_async watcher to listen on 2. if there arrives a new connection on listen thread, the listen thread creates an ev_io watcher and puts this on the lock free queue of a worker thread. 3. the listen thread notifies the worker thread with av_sync_send() 4. the callback of this ev_sync takes all the ev_io watchers from the queue and start watching on these watcher. I don't know if this implementation always works, because I'm not sure that the worker thread catches all async events from the listen thread. So can it be possible that when the listen thread wants to notify a worker thread using ev_sync_send, that the callback isn't call ? Is it possible to avoid this lock free queue ? Is it for instance thread safe to start the ev_io watcher from the listen thread and then call only av_sync_send() ? I.e can I do the follow call from the listen thread 1. ev_io_start(evLoop, watcher), where evLoop is the worker thread event Loop (I suppose not) 2. ev_async_send(evLoop,asyncWatcher) (this call is fine ?) regards
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
