Russell Warren wrote:
> Thanks for the detailed repsone... sorry for the lag in responding to
> it.
[discussion of problems with timeouts on threaded code's sockets]
>
> Not quite what I was after I don't think since potentially interfering
> code needs to check the lock (via acquire) to avoid con
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 t
Russell Warren wrote:
> It appears that the timeout setting is contained within a process
> (thanks for the confirmation), but I've realized that the function
> doesn't play friendly with threads. If I have multiple threads using
> sockets and one (or more) is using timeouts, one thread affects th