Re: state of threads in 1.9

On 14/11/2007, Luis Lavena <[e-mail]> wrote:
> On Nov 14, 2007 4:18 PM, Bill Kelly <[e-mail]> wrote:
> >
> > From: "Berger, Daniel" <[e-mail]>
> > >
> > > Really, the only time that I've needed native thread support is for
> > > extending existing C libraries. I don't see the upside for general
> > > concurrency, since we're not getting multi-core support anyway.
> >
> > No multi-core support... ever?  I had presumed native threads were
> > a step in that direction.  (No?)
> >
>
> They didn't say that :-P
>
> The thing is that some C extensions currently coded don't are
> thread-safe, so weird things could happen (including crashes and loss
> of profit) ;-)
>
> From my POV, is a ongoing process to be fully thread-safe, when that
> goal is achieved, the lock around this issue will be removed.
>

If the only fear is that extensions won't be thread-safe why not let
the extension author declare that in the extension in some way. This
can be checked at extension load time.

That way the interpreter could use concurrent threads by default, and
handle not-yet thread-safe extensions. There are several possibilities
how to do that (in order of decreasing flexibility and probably also
implementation complexity):

 - lock some global lock on entering the unsafe extension
 - start using the lock once the extension is loaded
 - require an option when the interpreter is started to switch on the
lock and allow loading extensions not marked as thread safe

As 1.9 is supposed to be some sort of beta release even the last
option should be acceptable for that.

Thanks

Michal