Threads and socket.setdefaulttimeout

[Russell Warren]

Thanks for the detailed repsone... sorry for the lag in responding to
it.

After reading and further thought, the only reason I was using
setdefaulttimeout in the first place (rather then using a direct
settimeout on the socket) was because it seemed like the only way (and
easy) of getting access to the seemingly deeply buried socket being
used by xmlrpclib.  That was prior to me using threads of course.  I
then started trying to make this solution work with thread, but it is
now too convoluted as you say.  Now I think the best solution is likely
to redirect my efforts at getting access to the socket used by
xmlrpclib so that I can set it's timeout directly.  I'm still unclear
how to do this cleanly, though.

Getting to some of your comments.

> When you say "one thread affects another", I see that your example uses
> the same function for both threads. IMHO it's much better to override
> the thread's run() method than to provide a callable at thread creating
> time. That way you can be sure each thread's execution is firmly in the
> context of the particular thread instance's namespace.
>
> having said all this, I don't think that's your issue.

Correct - the bottom code is nothing to do with my code and was only to
quickly prove that it was cross-thread.

> This seems extremely contorted, and I'm pretty sure we can find a better
> way.

Couldn't agree more!

> The threads' network calls should be yielding process control during
> their timeout period to allow other runnable threads to proceed. That's

Yep.  This is not causing me any problem.

> You are aware, I presume, that you can set a timeout on each socket
> individually using its settimeout() method?

Yes, but I momentarily had forgot about it... as mentioned I ended up
making the since-bad choice of using setdefaulttimeout to get timeouts
set on the inaccessible sockets.  Then I carried it too far...

> See above. However, this *does* require you to have access to the
> sockets, which is tricky if they are buried deep in some opaque object's
> methods.

Any help on how to crack the safe would be appreciated.

> There are locks! I suspect what you need is a threading.Rlock object,
> that a thread has to hold to be able to modify the (global) default
> timeout. This isn't a full solution to your problem, though, as you have
> correctly deduced.

Not quite what I was after I don't think since potentially interfering
code needs to check the lock (via acquire) to avoid conflict.  What I
guess I mean is something general for the process saying "never ever
interrupt this block og code by running code on another thread,
regardless of whether the other thread(s) check a lock".  Thinking more
about it it seems unreasonable so I'll drop the question.

Russ