semaphores and Rlocks

[Martin v. Löwis]

Jive Dadson <sdfadfsa at sdfasdfasdfa.invalid> writes:

> > > But I also found thread.c in the C sources, which appears to
> > > define semaphores and locks by means of the MS Windows API.

> > Where did you find this?
> 
> It's in a source distribution labeled 2.2b1. 

Can you please be more specific? Which file and line?

> > If you want threading objects implemented directly using the Win32 API,
> > see http://python.org/sf/500447.
> 
> I would prefer a portable solution.

I fear that a portable solution is unimplementable. Strictly, using
threads is already non-portable, since some platforms may not support
threads at all. Even on those who do, adding timeouts may not be
possible.

Please understanding that the polling approach taken for timed
condition variables isn't that evil: It isn't busy wait, yet it is
relatively responsive. Unless you critizise these
quality-of-implementation properties, I fail to see the point of your
objection: The interface that the object offers is without flaws,
right?

> I would be happy to contribute something in this area.  I would need
> an experienced Python programmer to prepare it for release, though.
> I don't know all the conventions, idioms, and gotchas.

Don't worry about this too much. An expert on cross-platform threading
libraries is needed, experts on Python core we have plenty.

It would be best if you could provide primitives that allow to exactly
replace the threading.py classes with native calls, preserving there
interface exactly. Preserving their semantics exactly isn't completely
necessary, as you want to improve responsiveness in case of timed
condition variables.

If that is not possible, extending the set of primitives is an option,
but please understand that this would need to work on all platforms
that currently support threading.

Regards,
Martin