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

Reply via email to