semaphores and Rlocks

[Jive Dadson]

"Martin v. Löwis" wrote:
> 
> 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?


I erred.  It is in thread_nt.h (dot h???) line 89, for example.

> 
> > > 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.

Portable to me means portable to at least Win32 and Unix/Linux/POSIX machines, using no C extension modules other than ones that come with the official Python distribution.  Mac and platforms are not too important to me.  This is for an industry where Macs are are rare as hen's teeth.  BTW, Win32 does not necessarily mean Microsoft.  I have applications that run under a realtime OS that has a Win32 compatible API extension.  I haven't tried running Python on it yet, but I'll wager I can make it work.

> 
> 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?

The interface is simple and clean.  I have no problem with that.  Perhaps I don't understand the code.  I have not studied it carefully.  But it looks to me as though the implementation puts the thread to sleep for periods of time during which a notify would be defered.  On some machines I use, the minimum amount of time you can sleep is 10 whopping milliseconds - a computer eon. 

> 
> > 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.
> 

I don't quite grok the next section:

> 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.
> 

I can't figure out the antecedants of all the pronouns in the preceeding block.  And I'm not sure exactly what you mean by "provide primatives".  I probably understand the software engineering principles involved.

Do you know off hand which platforms currently support threading?  BTW, I speak Win32 and some dialects of Unix, but I don't speak Mac.

Well, I think I understand some things better now.  You have been a great help.  If I come up with anything that might be of use to the Python community in general, I will be glad to share it.

Best regards,
Jive