Re^3: Managing C library memory in XS

I would go so far as to predict rather-emphatically that it wouldn’t. And, in any case, it would be highly dependent upon (read: “would introduce a whale of a dependency upon ...”) the exact internal implementations of that library. Warning-bells going off all over the place here.

Also worth heavy consideration here is the temporal issue: having been given a live memory-address, how long is that address actually going to be “good?” Your Perl app could now potentially modify (read: “muck around with”) that memory at any future-time. How predictably-stable do we consider that situation to be? In other words, how bad are the nasty-bugs going to be, if when they start to occur? These are design considerations that, to my way of thinking, absolutely overwhelm most all other concerns most of the time. So to speak, “I don’t really care if it screws-up ‘very quickly.’ ” I care that the solution is robust and thoroughly diagnosable. (And yes, it depends entirely upon the library.)

Replies are listed 'Best First'.
Re^4: Managing C library memory in XS by petermogensen (Sexton) on May 05, 2014 at 18:55 UTC
I would go so far as to predict rather-emphatically that it wouldn’t. And, in any case, it would be highly dependent upon (read: “would introduce a whale of a dependency upon ...”) the exact internal implementations of that library. Warning-bells going off all over the place here. I agree fully. Unless the library provided deep copy routines for every relevant struct, this is not going to work. having been given a live memory-address, how long is that address actually going to be “good?” Your Perl app could now potentially modify (read: “muck around with”) that memory at any future-time. First: The scenario is that the C library doesn't make any requirements about when the correct free function is called. Only that it should be called. In C that would often (but not always) lead to symmetric allocations/de-allocations to prevent leaks, but there's nothing to say that free_() can't be called at any time later at the will of a reference count engine. Secondly: You have alluded to the Perl app "mucking around" earlier. I don't really share that concern. I mean... any* Perl module will break spectaculary if the Perl app started trashing its objects. Take the JSON::XS module. What would happen if I did: `my $json = new JSON::XS; substr($$json,0,1) = 'X'; # the object is a ref to a PV` [download] I would simply set a byte in the start of *JSON on the C side. No module needs to protect against a perl app using anything but the defined API on the objects/vars it return.	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Managing C library memory in XS
by petermogensen (Sexton) on May 05, 2014 at 18:55 UTC

I would go so far as to predict rather-emphatically that it wouldn’t. And, in any case, it would be highly dependent upon (read: “would introduce a whale of a dependency upon ...”) the exact internal implementations of that library. Warning-bells going off all over the place here.

I agree fully. Unless the library provided **deep copy** routines for every relevant struct, this is not going to work.

having been given a live memory-address, how long is that address actually going to be “good?” Your Perl app could now potentially modify (read: “muck around with”) that memory at any future-time.

First: The scenario is that the C library doesn't make any requirements about when the correct free function is called. Only that it should be called. In C that would often (but not always) lead to symmetric allocations/de-allocations to prevent leaks, but there's nothing to say that free_*() can't be called at any time later at the will of a reference count engine.

Secondly: You have alluded to the Perl app "mucking around" earlier. I don't really share that concern. I mean... any Perl module will break spectaculary if the Perl app started trashing its objects. Take the JSON::XS module. What would happen if I did:

my $json = new JSON::XS;
substr($$json,0,1) = 'X';  # the object is a ref to a PV
[download]

No module needs to protect against a perl app using anything but the defined API on the objects/vars it return.

[reply]
[d/l]