Re: [0.5] Threads?

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

Hi prez,

I understand your concerns regarding the implementation of threading within libssh. In a perfect world, a well designed lib using contexts like libssh should be compmetely threadsafe after initialization. That's even what i though before receiving a bug report of Sayan from Webyog, who had a crash somewhere in openssl in a heavily threaded program. I reproduced the crash and had to accept the evidence : backend crypto libs are not threadsafe.
This means, as someone from libssh2 ml told (sorry, no ref available from my phone), 3 options:
- we ignore it
- we let caller initialize third party xrypto libs. Ugly and unsafe
- we add our own locking system. However, linking with pthread and similar is mandatory
- we leave our own callback hooks and let user decide for us.

I think the later option is the best and is what i implemented. However as workaround for older programs, i think an optional feedback on #3 is good too.

So, your singlethreaded app should'nt be impacted if you compile libssh without #3. it's unfortunate but we can't simply ignore threading anymore.

Aris

Envoyé de mon téléphone.

Le 4 sept. 2010 à 22:21, <prez@xxxxxxxxxxxxxx> a écrit :

> Aris,
> 
>  
> 
> I noticed you putting in threading logic for 0.5.  Can you tell me what the reason for this is?
> 
>  
> 
> I’m wary of having threads integrated with libssh, and so far I cannot find much reason for it.
> 
> Given that everything uses handles, all data for a session (be it a ssh session or crypto session) should be contained within that handle, nothing should be global or function-level static.  If this is the case, then there should be no need for mutexes, regardless of how many ssh sessions there are.
> 
>  
> 
> Theoretically I should be able to run any number of ssh sessions from a single thread, in which case locking is unnecessary.
> 
>  
> 
> The only situation I can think of requiring locks like this is the situation of:
> 
> Thread A receives data from transport and invokes libssh to ‘notify’ the data has arrived and what it is.
> 
> Thread B needs to invoke a callback (for whatever reason) on the same session.
> 
>  
> 
> But this can still be handled without needing to implement threading directly into libssh.
> 
>  
> 
> PreZ