Python threading (was: Re: global interpreter lock not working as it should)

[Martin v. Löwis]

bokr at oz.net (Bengt Richter) writes:

> >They should also know that
> >linuxthreads most likely is *not* a typical representative of these
> >things, since Linus refuses to support threads in the OS kernel (as
> >opposed to merely supporting processes); until very recently.
> >
> Ok, I'm being lazy ;-) Do you mean that LinuxThreads is probably
> not underneath Python threading in RH7.3, for example (which I will
> install in a few weeks)? 

Sure: on Linux, Python threads are LinuxThreads threads, which, in
turn, are Linux clones.

However, LinuxThreads are not a typical representative of POSIX
threads. Thinks are likely done differently on *BSD, Solaris, Irix,
and HP-UX (which, in turn, is not a typical representativ, either).

> My impression is that some apparently think there is a latency problem
> for some applications.

I understand that these concerns do not come from real-world
applications, so I'm not concerned.

> Seems like if unneeded calls to release the GIL could be eliminated
> cheaply, that would be on target for this item?

Sure. Notice that this is already a tunable setting in the sysmodule.

> >c) provide a minimum amount of fairness, if the underlying system has
> >   some guarantee of fairness. IOW, starvation should not be observable
> >   in real life.

> Seems like if calls to release the GIL _and_ transfer ownership of
> the lock could be implemented cheaply -- to be used _when
> appropriate_ to minimize context switch latency -- that would be on
> target for this item?

There is, of course, also the issue of maintainability and
portability, which should not suffer. If you then can get better
fairness with no loss of performance, that would be good.

Regards,
Martin