As for caveats with regard to threading

It's a normal Perl scalar. It will get cloned on thread creation like every other. Each thread will be accessing its own copy of it. No problem.

Update: s/a different/its own/

Each thread will be accessing a different copy of it

I would have expected the copies to be identical, and that the SvREADONLY_on would ensure that they stay identical.
Of course, my expectations are often wrong - especially re threads. (IOW, someone please correct me where necessary.)

Cheers,
Rob

yes, they're identical copies

$ perl -le "sub LUCY(){66} use threads; async{ print join q/ /, thread
+s->tid, LUCY(), \&LUCY() } for 1..3; sleep 1; "
1 66 SCALAR(0xb6c0d4)
2 66 SCALAR(0xbf7144)
3 66 SCALAR(0xc7eebc)
Perl exited with active threads:
        0 running and unjoined
        3 finished and unjoined
        0 running and detached
[download]

$ perl -le "use Readonly; Readonly::Scalar $LU => 66; use threads; asy
+nc{ print join q/ /, threads->tid, $LU, \$LU } for 1..3; sleep 1; "
1 66 SCALAR(0xb84cfc)
2 66 SCALAR(0xc1bbec)
3 66 SCALAR(0x10af0b4)
Perl exited with active threads:
        0 running and unjoined
        3 finished and unjoined
        0 running and detached
[download]

Of course they're identical copies; I was saying that each thread gets its own copy. Updated wording in this post's grandparent.

I tried just using GV_ADD, but it gave me a segfault:

mymodule.xs:113 is where I'm calling SvIV_set. The same thing happens if I leave $CONSTANT_NAME in the use vars statement, but don't initialize it in BEGIN.

Address 0x18 is not stack'd, malloc'd or (recently) free'd

That suggests that get_sv() is returning an invalid SV*; which it shouldn't, if the docs are to be believed:

get_sv

Returns the SV of the specified Perl scalar. flags are passed to gv_fe
+tchpv. If GV_ADD is set and the Perl variable does not exist then it 
+will be created. If flags is zero and the variable does not exist the
+n NULL is returned.

NOTE: the perl_ form of this function is deprecated.
        SV*     get_sv(const char *name, I32 flags)
[download]

I think your only course of action (other than sticking with the way you have that works) is to write a minimal testcase and raise a perlbug.

P5p will either: correct the code; or correct my interpretation of the docs.

Of course, any resolution will take time, so you'll probably need to stick with what you originally had for now anyway. Sorry for the bum steer.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

That suggests that get_sv() is returning an invalid SV*; which it shouldn't, if the docs are to be believed:

:) nope, its the call to SvIV_set thats causing it, solution i use is sv_setiv

    SV* const_sv = get_sv( "Soivro::SOIVRO", GV_ADD );
    sv_setiv( const_sv, FILENAME_MAX );
    SvREADONLY_on( const_sv );
[download]

Fair enough. Hopefully in the near future I'll have some time to look into this more deeply. For now, as long as my original approach looks valid (if perhaps not stylistically optimal) I'll stick with that. Thanks for the input.