henrik.holst at millistream.com
Mon Feb 4 17:04:33 EST 2013
I agree that there's a place for an official way of aborting a session, but
I fail to grasp your example.
#1 neon isn't thread safe so the two threads shouldn't be sharing the same
session to begin with, and if they did then they would have to protect it
with a mutex anyways.
#2 closing a file descriptor can be done at any time so one does not have
to wait for connect() to succeed(?).
2013/2/4 Patrick Ohly <patrick.ohly at gmx.de>
> 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?
> Bye, Patrick Ohly
> Patrick.Ohly at gmx.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the neon