I think you need an internal queue and accept or reject writes
atomically at the API level. Anything else is crazy-time for callers.
Chris
On 4/11/2013 1:49 PM, Eric Frias wrote:
> On 4/10/2013 6:44 PM, Chris Hecker wrote:
>> This is the recent thread where I had similar issues:
> Thanks for the pointer, I don't know how I missed these messages when I
> was trying to figure out the problem. It looks like the problem is
> pretty well understood, and the problems I'm seeing were described in
> one of the messages you linked from Henrik Nordström back in 2011.
>> I only thought about/debugged it a bit, but it seemed pretty clear to
>> me that the only real fix is an internal queue and changing EAGAIN
>> semantics slightly, as discussed in that thread.
> That was my first thought too, and it looks like that was the general
> consensus. I'm aiming to use libssh2 in production code, so I might
> take a crack at it once I get a better handle on the problem.
>
> Even if we can make simple calls like channel_read/channel_write behave
> well, there may still be restrictions on some of the higher-level API
> functions. It seems like we'll end up with two classes of function:
> things like libssh2_channel_write where and EAGAIN means that nothing
> was written and there are no restrictions on what your next API call is;
> and calls like libssh2_scp_send_ex where an EAGAIN might mean that part
> of the scp_send has executed and it has state saved in the session
> object. In the latter case, the user can still go on to call most other
> libssh2 functions before continuing the scp_send, but they can't start a
> call to scp_send with different arguments to start sending a different
> file because it would screw up the information in the session's
> scpSend_state.
>
> The use case I'm envisioning is a multi-threaded app that could be doing
> file transfers in several threads. A mutex tied to the session will
> prevent two threads from accessing libssh2 at the same time, but it
> wouldn't do anything to prevent two scp_send calls from interleaving
> with each other. It's easy enough to avoid that case, but it's
> important to know what I need to avoid to stay safe.
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2013-04-11