asynchronous socket writing

Graham Leggett minfrin at
Thu Mar 11 16:48:02 CET 2010

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.


More information about the libev mailing list