On 11 Mar 2010, at 4:54 PM, Jonas H. wrote:
Thanks for that lot of answers!
I think you're right with avoiding thread for now. Actually I don't
really need/want threads, I just didn't know there's another way to
go (nonblocking I/O).
What I don't really get is: If libev is event-driven, why won't I
get other 'accepts' while there's already another transaction going
on in the background? (I've set both sockets to be nonblocking.)
Does this need special setup?
The event loop only ever calls the callbacks one at a time, while the
thread of execution is inside one of your callbacks, everything else
is on hold until you're done.
It's for this reason that you need to be extra careful about how much
work you choose to do within your event callback. For example, you
might respond to a callback by (say) walking a directory tree. When
the directory tree is small, the callback executes quickly, and all
seems fine. But if the directory tree is suddenly large, you entire
app stops dead while your callback walks the large directory tree, and
the user experience suffers.
One of the things libev gives you is a "run me when you're not busy"
event, which allows you to break large tasks into small subtasks (for
example, process one directory, set up the next event to process the
next directory).
This method can be used to ensure your event loop doesn't get stuck
behind something that either blocks or takes a long time.
Regards,
Graham
--
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
