"The remote end closing the connection" is detected by getting EOF on a read. So to detect that you actually have to read everything the remote end sends first... Thus your requirements of not reading anything and detecting the remote end closing the connection are not compatible.
The documentation states
"When an error or an end-of-stream in the read direction occurs, close_cb will be called. errno will return the error, or zero in the case of an end-of-stream.
The name of this callback is rather unfortunate since it really has nothing to do with a close: The stream is still open when close_cb is called (you might not be able to read and/or write to it, but you can still use things like query_address, and the underlying file descriptor is still allocated). Also, this callback will not be called for a local close, neither by a call to close or by destructing this object.
Also, close_cb will not be called if a remote close only occurs in the write direction; that is handled by write_cb (or possibly write_oob_cb)."
As I read it, I should get a cloase_cb when the stream is closed in my read direction. Am I reading it wrong or is the documentation wrong?
Ah, right. *doh* My bad. It's the write direction I'm having issues with.
I guess I can just discard any incoming data and live with that, but I'm still interested - how would one know that the pipe goes from being write only to fully closed?
In the normal case, without Stdio.Buffer, I assume write() would return an error?
Are you trying to detect the case where a push of data would be replied to with a TCP packet with RST set? That happens asynchronously, so I'm not sure write() would return an error. Maybe the _next_ call to write(). You might be able to get a SIGPIPE or something.
Pretty much.
Basically, I want to output log to a socket. Once a client disconnects from that socket, I want to ensure I don't keep trying to send data to that socket.
Since I'm not interested in any input from the client, it seemed to make sense to close my end in the read direction, but if that doesn't work, I'll just keep it open and discard incoming data.
pike-devel@lists.lysator.liu.se
-
Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum