Bill Allombert on Sat, 16 Sep 2006 18:42:50 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: PARI_stack_limit

On Sat, Sep 16, 2006 at 05:05:17PM +0200, Bernard Parisse wrote:
> >
> >But you run exactly one thread at once ?
> >
> currently, yes, but this could change in the future, when giac
> will be thread-safe. If pari is not thread-safe, I will use a
> mutex lock.

PARI is (more or less) thread-safe when compiled with --enable-tls but this 
breaks the libpari ABI, so it might be better to assume it is not.

> >Could you write a stand-alone test case ? It would help.
> >
> That would be too long, it's faster that you compile giac with
> run gdb on icas and make a breakpoint in, line 426.
> Then for example
> (gdb) r 'pari("sin",x)'
> will stop just before flisexpr is called
> The call comes (f 1) from the _pari function, and you will see
> at line 556 that I replace PARI_stack_limit by 0
> > Well being thread-safe is another issue (See Configure
> > --enable-tls). It seems to me that we could make the function
> > pari_init_stackcheck public, and require you call it a the
> > start of each threads. We should also provide an init_opts
> > flag to deactivate it.
> But there are global variables inside PARI, right? How can you make
> PARI thread-safe if there are global variables remaining?

We use the thread-local storage (TLS) support on modern systems. You
'just' need to add __thread to declaration of all global variables,
like in:
extern __thread long avma;

Every threads will see a different variable. You just need to take
care of initializing all such variables when starting a new thread.
(that is what pari_thread_init() do) and freeing them before closing
a thread (that is what pari_thread_close() do).

That exactly what Configure --enable-tls do.

(it can be considered as cheating...)