[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [0.5] Threads?
- Subject: Re: [0.5] Threads?
- From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Sun, 5 Sep 2010 12:38:26 +0200
- To: "libssh@xxxxxxxxxx" <libssh@xxxxxxxxxx>
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