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, <[email protected]> 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
