patrick.ohly at gmx.de
Tue Feb 5 08:21:54 EST 2013
On Mon, 2013-02-04 at 19:10 +0100, Patrick Ohly wrote:
> On Mon, 2012-12-10 at 15:31 +0100, Henrik Holst wrote:
> > Try to call ne_close_connection() or close the ne_session->socket hard
> > should probably force a pending read/write/connect to abort.
> The docs for ne_close_connection() don't allow that:
> "Use of this function is entirely optional, but it must not be
> called if there is a request active using the session."
> Looking at the source confirms that bad things will happen if this is
> attempted, like freeing the ne_socket instance that is still in use by
> functions like ne_request.c:read_response_block.
> ne_session->socket is not accessible from outside of neon itself as far
> as I can tell. Even if it was available, there would be race conditions:
> * Thread A starts worker thread.
> * Thread A wants to abort by closing the file descriptor, but
> cannot do that yet because the session is not yet connected.
> * Thread B connects and gets blocked.
> Basically thread A would have to poll until it can kill the connection,
> instead of preventing it from being opened in the first place.
> Overall it seems to me that a new, dedicated, thread-safe ne_session_*
> API call will be needed to allow aborting of a running request. Agreed?
Supporting this for all three transport layers inside neon (plain fd,
OpenSSL, GnuTLS) will be some work, but it looks feasible. Is this
something that would be acceptable?
Here some pointers, also for my own future reference.
OpenSSL: implement a BIO
GnuTLS: transport functions
Bye, Patrick Ohly
Patrick.Ohly at gmx.de
More information about the neon