Re: XS: exposing C++ library constant as package variable

Replies are listed 'Best First'.
Re^2: XS: exposing C++ library constant as package variable by ikegami (Patriarch) on Oct 07, 2015 at 21:39 UTC
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/	[reply]
Re^3: XS: exposing C++ library constant as package variable by syphilis (Archbishop) on Oct 08, 2015 at 05:27 UTC
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	[reply]
Re^4: XS: exposing C++ library constant as package variable by Anonymous Monk on Oct 08, 2015 at 07:46 UTC
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]	[reply] [d/l] [select]
Re^4: XS: exposing C++ library constant as package variable by ikegami (Patriarch) on Oct 08, 2015 at 17:29 UTC
Of course they're identical copies; I was saying that each thread gets its own copy. Updated wording in this post's grandparent.	[reply]
Re^2: XS: exposing C++ library constant as package variable by wisnij (Novice) on Oct 08, 2015 at 14:54 UTC
I tried just using GV_ADD, but it gave me a segfault: Read more... (4 kB) 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.	[reply]
Re^3: XS: exposing C++ library constant as package variable by BrowserUk (Patriarch) on Oct 08, 2015 at 15:11 UTC
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.	[reply] [d/l]
Re^4: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by Anonymous Monk on Oct 08, 2015 at 22:42 UTC
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]	[reply] [d/l]
Re^5: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by ikegami (Patriarch) on Oct 09, 2015 at 05:27 UTC
Re^6: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by wisnij (Novice) on Oct 14, 2015 at 16:19 UTC
Some notes below your chosen depth have not been shown here
Re^5: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by BrowserUk (Patriarch) on Oct 08, 2015 at 23:44 UTC
Re^6: XS: exposing C++ library constant as package variable ( sv_setiv , SvIV_set ) by Anonymous Monk on Oct 08, 2015 at 23:51 UTC
Some notes below your chosen depth have not been shown here
Re^4: XS: exposing C++ library constant as package variable by wisnij (Novice) on Oct 08, 2015 at 18:00 UTC
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.	[reply]


Problems? Is your data what you think it is?
	PerlMonks