Problem with threading on Solaris

[Tim Peters]

[Lionel Ulmer, has trouble getting threads to timeslice on some
 flavor of Solaris]

Solaris people have reported that often; the usual workaround seems to be to
sprinkle their code with time.sleep(0.1) (or other small values).

> ...
> Just to follow-up on myself, I just did some tests with pthread on my
> Solaris box. And to have what I feel to be the 'correct' behaviour on
> pthread, you need to do that :
>
>   pthread_attr_init(&attr)
>   pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)
>
> And use these attributes at thread creation.

Cool!  If you're sure this will work under all Solaris releases, please
submit a Solaris patch to SourceForge (you can't assume this won't harm
other platforms -- or even compile on other platforms -- and it needs to be
#ifdef'ed by the version of pthreads in use too, since PTHREAD_SCOPE_SYSTEM
didn't always exist).

> With these options, the thread are running 'concurrently'. Now, I did
> not see anywhere on Python documentations what the scheduling model is
> for threads...

Python isn't an operating system:  it doesn't schedule threads.  That's
entirely up to whatever thread package you use.

> ...
> I thought that the way it was planned to work was to 'round-robin'
> through the different threads (ie shcedule them as Unix processes are
> scheduled).

Python's global interpreter lock (GIL) prevents more than one thread running
concurrently *in* the PVM, and every N bytecodes gives a different thread a
*chance* to run by releasing the GIL (so another thread can acquire it).
Whether a different thread actually gets control then isn't Python's
decision.  For whatever reason on Solaris (I guess you'd have to ask Sun),
their default pthreads behavior is extremely reluctant to switch threads.
OTOH, Windows is very eager to switch threads.  And so on -- YMMV.