According to Michael J.Pomraning : > > No, GLOB_ERROR is actually stored in a thread specific place. > > Hmm -- could you try the following example? For me, Thread #1 changes > the return value of GLOB_ERROR() out from under (the older) Thread #0: I can see that. I don't know why it behaves that way ; I just hope this doesn't indicate a bug in the code generated by ExtUtils::Constant or in MY_CTX. > $ cat glob2.pl > use threads; > use File::Glob qw|:glob|; > use strict; > > sub globerr() { > print "Thread ", threads->tid, " GLOB_ERROR():", > GLOB_ERROR(), "\n"; > } > > sub e($) { > my $g = shift; > print "calling glob()\n"; > bsd_glob($g); > globerr(); > } > > e("/tmp"); > threads->create(\&e, '/root/eacces*')->join; > globerr() > > $ perl glob2.pl > Thread 0 calling glob() > Thread 0 GLOB_ERROR():0 > Thread 1 calling glob() > Thread 1 GLOB_ERROR():-2 > Thread 0 GLOB_ERROR():-2 > > Same config as before. It surely looks to me like the value being > returned is shared across threads: TID 0 glob()s, checks error, spawns > TID 1 to do the same; after TID 1 completes, TID 0 checks error again, > and (voila) it has changed. > > I think I understand what the XS is trying to do, I just don't see that > behavior. > > > I don't know if it's possible to register code to be called at > > interpreter clone time. It so, we could make it reset GLOB_ERROR. > > ISTM that storing the C return value of glob() in an ordinary, unshared > package lexical, and having GLOB_ERROR() fetch that, would have the > desired effect.Thread Previous | Thread Next