> > until (say) threads::shared::bootstrap() populates the function pointers. > > I see threads.pm says: > : It is also important to note that you preferably enable threads by > : doing C<use threads> as early as possible and that it is not possible > : to enable threading inside an eval ""; In particular, if you are > : intending to share variables with threads::shared, you must > : C<use threads> before you C<use threads::shared> and threads will emit > : a warning if you do it the other way around. > > but "preferably" seems way too weak. You *must* use threads and > threads::shared if required *before* loading any extensions > (or any module that might load extensions). > > I think it would be good if the stub hooks for SvSHARE and SvLOCK > incremented a counter. Then if threads.xs is loaded and the counter > is non-zero a warning can be given. > > > If you want same kind of abstraction for lighter-weight non-recursive > > MUTEX stuff now would be a good time to make the case. > > SvLOCK doesn't look too expensive. And it's basically doing just > what the DBI already does (looping on a COND_WAIT). So I'm happy > to dump my code and use yours :) Thanks. > > There ought to be some pointers to this stuff in perlguts and perlxs.
What's the old adage? Oh, yes, "patches welcome" :-) Note that I'm quite serious, here: since you are an "old threads user", your notes about migration to "new threads" for XS writers would be really spot on. > Currently only perlapi.pod mentions SvSHARE and SvLOCK (and you > have to know what you're looking for before you read perlapi.pod :) > Both should refer to each other and mention the interaction with > the threads module. > > Thanks for the pointers Nick. > > Tim. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
