Re: libssh thread support

[Andrew Tappert <andrew@xxxxxxxxxxxx>]

This leads me to think that threads aren't the right solution for me, so
I explore other parts of your tutorial.  I see this:

"Warning: ssh_select() and ssh_channel_select() are not relevant
anymore, since libssh is about to provide an easier system for
asynchronous communications. This subsection should be removed then."

What is the easier system for asynchronous communications?  When will it
be available?

Andrew


On 04/14/2011 04:58 AM, Aris Adamantiadis wrote:
> Hi,
> 
> I see a typo in the tutorial. You should read "your *can't* use several
> channels in a same session at the same time".
> So, let C be a channel, you cannot do
> thread 1:
>  ssh_channel_read(C,...)
> thread 2:
>  ssh_channel_write(C, ...)
> 
> You will have to use your own locking to avoid reads during your writes
> and vice-versa.
> 
> Kr,
> 
> Aris
> 
> Le 13/04/11 22:54, Andrew Tappert a écrit :
>>
>> I'm considering using libssh in an application I'm developing.  I would
>> be using libssh to execute a program on the server, and my application
>> would then speak an application-specific binary protocol with that
>> program.  In this protocol, the requests and responses are asynchronous,
>> so I would have a reader thread that reads "responses" from the ssh
>> connection, while the main thread writes "requests" to it.  Is this
>> possible with libssh?  Would I need locking so that a read and a write
>> don't occur simultaneously?
>>
>> In the libssh tutorial, I see the following:
>>
>> "At all times, you may use different sessions inside threads, make
>> parallel connections, read/write on different sessions and so on. You
>> can use a single session in several channels at the same time. This will
>> lead to internal state corruption. This limitation is being worked out
>> and will maybe disappear later."
>>
>> Could you please clarify this statement?  I don't think it is clear what
>> it is exactly that will lead to internal state corruption.
>>
>> Thanks,
>> Andrew