Oh, should mention that depending on what you are trying to do in detail,
you may not want to use bufferevent_free and instead use "shutdown" calls.
I.e. the "correct" way to close a socket (buffer event) is basically the
following (sorry if I'm stating the obvious):
<assuming server initiates the shutdown>
1. Server writes the last of its data. Maybe an exit message. Uses
the watermark setting to know when all data is flushed then calls "shutdown(
fd, SHUT_WR )" to inform the other side that it is completely done writing.
2. Client receives an event callback with read | eof as the "what",
calls shutdown( fd, SHUT_RD ).
3. Client sends the rest of it's data and uses the watermark setting
the same way as the server. When all data is flushed, it calls shutdown(
fd, SHUT_WR ). At this point it is completely safe to call bufferevent_free
as intended.
4. Server receives the EOF, it can now call the free as intended.
Following this pattern simply guarantee's that no data incoming or
outgoing is lost and/or truncated in the shutdown process. Of course for
some things, simply closing without the above is valid as you can see in the
examples with libevent. So this really depends on what you are trying to
accomplish. Anything with a request/response pattern though is typically
best done using the full handshaked shutdown procedure.
KB
> > Hey,
> > I understand Simon's view on how not to close buffer event sockets, but
> > can some one explain why thishttps://gist.github.com/714606idea is bad?
>
> I don't feel "strongly" that this is incorrect; Simon may have more
> information on this. But, basically it is just added overhead to do it
> that
> way since you will get repeated calls to the callback which may or may not
> be related to what you want. I.e. you may get 10-100 calls to the
> callback
> if there is a lot of work remaining.
>
> If you use the watermark you don't have to do any checks or worry
> about multiple callbacks. The next time you get a write callback you
> simply
> know it is safe to close the buffer. My understanding of the info
> callback
> is that it is meant more for pure information gathering, i.e. kb/s
> tracking
> for instance.
>
> But, it seems like the solution you found can work, just seems like
> it's not the best way.
>
> KB
>
> ***********************************************************************
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users in the body.
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
