Question about ngx_handle_write_event

[Maxim Dounin]

Hello!

On Wed, Jul 17, 2019 at 02:35:02PM +0000, Eran Kornblau wrote:

> > 
> > Hello!
> > 
> > On Mon, Jul 01, 2019 at 07:23:11PM +0000, Eran Kornblau wrote:
> > 
> > > Something is unclear to me regarding the use of this function, the 
> > > development guide says - "the functions ngx_handle_read_event(rev, 
> > > flags) and ngx_handle_write_event(wev, lowat) must be called after handling an I/O socket notification or calling any I/O functions on that socket"
> > > 
> > > If my module finished sending all the data it had, and is now waiting 
> > > for more data to arrive (on some other socket) does it still have to call ngx_handle_write_event?
> > 
> > Yes.  In particular, this is required with level-tiggered event methods, such as select and poll, to remove the socket from the event list if it was previously added there.
> > 
> 
> Thank you, Maxim.
> 
> I'm looking at ngx_ssl_ocsp_write_handler, and I see that ngx_handle_write_event is called only when the request is fully sent -
> it is not called in case of NGX_AGAIN / partial send. 
> Is this a bug, or am I still missing something?

Sort of.

As write event is initially added when a connection is created, 
and never removed by the relevant code - ngx_handle_write_event() 
is not needed unless we've sent all the request and want to 
disable the event.  That is, this shouldn't be a problem with 
currrent code, as everything will work as intended.  In more 
complex code ngx_handle_write_event() call is likely to be 
required after all write events, not just when you've done with 
writing.

This might be a bug with oneshot events though, but oneshot 
events are buggy regardless of this particular problem.

> Also, isn't there a need to call ngx_send repeatedly in a loop, if it somehow returns n < size? 
> (I see there is such a loop in ngx_linux_sendfile_chain for example)

No.  Calling send functions again is only needed to handle EINTR 
signals, and this is something nginx low-level functions do for 
you.

-- 
Maxim Dounin
http://mdounin.ru/