On Wed, Jun 30, 2010 at 9:33 AM, Nikolaus Rath <nikol...@rath.org> wrote: >> Nikolaus Rath wrote: >>> Hello, >>> >>> I would like to use an SFTPClient instance concurrently with several >>> threads, but I couldn't find any information about thread safety in the >>> API documentation. >>> >>> - Can I just share the SFTPClient instance between several threads? >>
Yes. Though you may have a use case, there's no performance benefit, as the client can only handle one operation at a time. >> Why use SFTPClient? Its performance might not be very good plus >> compatibility issues with some SSH servers might crop up. I know I had >> compatibility issues even with some pretty standard SSH servers on some >> platforms (esp. Solaris). >> There are throughput performance issues with older ssh servers that don't support prefetch and pipelining. On slower machines with fast network, crypto and transport overhead will be the limiting factor. > >> There's quite a number of rather nasty problems you need to deal with: >> for instance, what if you need to close down the thread in the middle of >> operation but SFTPClient doesn't allow that? > > When I'm in the middle of an operation, then I am in the middle of an > SFTPClient method. Obviously I can't shut down the thread while the > interpreter is not executing my code. This doesn't seem to be an > SFTPClient or even multithreading specific problem to me. > The same thing goes for SSHClient, and SFTPClient. In a way, they are "convenience" classes, that bundle a bunch of the library together. If you do things out of the ordinary, you may need to bypass their abstractions, and work with the lower level pieces yourself. The *Client code is fairly straightforward to use as an example if needed. > >> Obviously, all the normal caveats about multithreading apply: >> remembering to sleep just in case after releasing locks to prevent >> starvation > If you need to sleep after releasing a lock, there's something wrong (and arbitrary delays to solve contention are poor programming practice). As far as the python language is concerned, lock operations are atomic. -jim _______________________________________________ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko