Hello,
> > I've submitted a patch (*) to add an optional timeout to locking
> > operations (Lock.acquire() etc.). Since it's a pretty basic
> > functionality, I would like to know if there was any good reason for
> > not doing it.
>
> I always assumed it was because as a least-common-denominator
Antoine Pitrou writes:
> I've submitted a patch (*) to add an optional timeout to locking
> operations (Lock.acquire() etc.). Since it's a pretty basic
> functionality, I would like to know if there was any good reason for
> not doing it.
I always assumed it was because as a least-common-denomin
On Wed, Nov 18, 2009 at 8:50 AM, Antoine Pitrou wrote:
> Jesse Noller gmail.com> writes:
>>
>> Nick is right, many of the BSDs and FreeBSD up until fairly recently
>> did not have named shared semaphore support. Still yet, the behavior
>> is broken on some OSes such as OS X which you have to work
Jesse Noller gmail.com> writes:
>
> Nick is right, many of the BSDs and FreeBSD up until fairly recently
> did not have named shared semaphore support. Still yet, the behavior
> is broken on some OSes such as OS X which you have to work around.
The core locking support only uses anonymous se
On Nov 18, 2009, at 5:38 AM, Nick Coghlan wrote:
Antoine Pitrou wrote:
Guido van Rossum python.org> writes:
Will locks be interruptible with ^C? That is an oft-requested
feature
which also wasn't supported at that time; what's the situation
nowadays?
They still aren't interruptible. Fr
Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>> Will locks be interruptible with ^C? That is an oft-requested feature
>> which also wasn't supported at that time; what's the situation
>> nowadays?
>
> They still aren't interruptible. From what I can read it may be possible to
> m
Guido van Rossum python.org> writes:
>
> I think the number of platforms
> has dwindled to two or three (Posix, Windows, and maybe one minority
> OS?), so now's the time to do it. (IOW I think the idea of the patch
> is fine.)
Thanks. (the minority OS would be OS/2, I think)
> Will locks be int
I think I can answer the "why" question: thread.c is *very* old code,
in fact it predates the posix threads standard. When we (actually
Sjoerd Mullender) wrote it, we had a number of OS-specific locking
APIs to work with and the API was designed to fit all of them. I don't
even recall the initial s
