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 > CXXFLAGS=-g, > run gdb on icas and make a breakpoint in pari.cc, 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...) Cheers, Bill.