回复: Re: Should I use EV_WRITE event?

[钱晓明]

Thanks for the reply! I just read the source code of Redis, which has a IO event mechanism similar to libev. I find that it install write event when there is data to send back and remove it after all data sent. In callback function, Redis only send a fixed number of bytes to client if the reply data is too long, then return from this function without deleting write event. I think this is situation C.

2011-11-07



Kyle Qian



发件人: maarten <maarten.foque at edchq.com>
发送时间: 2011-11-07 16:49
主 题: Re: Should I use EV_WRITE event?
收件人: 钱晓明 <mailtoantares at 163.com>
抄 送: libev at lists.schmorp.de





If I understand what you are trying to do in situation B correctly, 
that callback function will be called each loop iteration. 
Pretty much (while(socket_connected)):callback() 

So B is a nono, 
if the data to send back is limited A will be sufficient and quickest to 
implement. 


regards, 
Maarten 

On Mon, 2011-11-07 at 11:23 +0800, 钱晓明 wrote: 
> Hi, I am working on libev few days, and there is a question about 
> EV_WRITE: 
> When processed request from client, the server has some data to write 
> back. At this time, it can: 
> A. write back directly in a loop, until all data has been written 
> B. install a EV_WRITE event when client connected, check buffer in the 
> callback function, and write back if there is data. The EV_WRITE event 
> only install once. 
> C. install/start a EV_WRITE event when adding reply data to buffer, 
> and in callback function write all data to client, stop EV_WRITE event 
> at last before returning from this function. 
> Which one is best? How frequent the callback function will be called 
> in situation B? 
>   
> Thanks in advance! 
>   
> Kyle Qian 
>  
>  
> _______________________________________________ 
> libev mailing list 
> libev at lists.schmorp.de 
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20111107/96140d2f/attachment.html>