The only potential issue for PDL that I can think of is when somebody
brute-force copies their binary PDL data by saying
$data_copy = ${$piddle->get_dataref};
Starting with v5.20, that won't make a copy. Here is a search for all uses
of get_dataref in PDL:
https://github.com/PDLPorters/pdl/search?utf8=%E2%9C%93&q=get_dataref
This is not to say that CoW won't give trouble somewhere else, just that I
can't imagine it doing so since PDL handles all of its memory management
internally.
David
On Fri, Sep 19, 2014 at 8:23 AM, Chris Marshall <[email protected]>
wrote:
> I'm concerned as well given that the types of problems
> described could cause real difficulty with working with
> PDL data from the perl level since it seems to cause
> spooky action at a distance that is different than all
> previous expectations.
>
> The use case that comes to mind is doing large data
> IO, say a stream of bytes, and then "casting" that into
> the desired piddle "in place" without a copy being
> forced.
>
> I haven't looked at 5.20.1 docs yet but are there some
> guidelines for how to avoid these types of problems
> that will work in a back-compatible fashion?
>
> --Chris
>
>
> On Fri, Sep 19, 2014 at 5:55 AM, Niels Larsen <[email protected]> wrote:
> > Rob,
> >
> > I found the discussion I think you refer to,
> >
> >
> http://grokbase.com/t/perl/perl5-porters/1325q5s51n/perl-116569-re-5-17-7-breaks-rules-of-assignment
> >
> > I and many others have code like yours, where a Perl string is passed
> > with SV* to C as an array, which is read and modified in C. I let Perl
> > do all memory management. I can change my own Inline/XS but
> > customers with existing code who update their Perl (or the sysop
> > does it rather) will get the breakage and I get the blame. This isn't
> > PDL stuff, but I just don't agree with the response you got. At least
> > they should support an environment variable that turns COW off, I
> > think. I will try again on the P5P list ..
> >
> > Niels L
> >
> >
> > On Fri, 2014-09-19 at 12:14 +1000, [email protected] wrote:
> >> -----Original Message-----
> >> From: Niels Larsen
> >> Sent: Friday, September 19, 2014 12:05 AM
> >>
> >> > I have not yet reported the problem and found no complaints with
> >> > Google, so maybe I missed something. Or have the Perl people
> >> > forgotten about Inline .. ?
> >>
> >> Inline will be subject to the same behaviour as XS.
> >>
> >> Only time I’ve been bitten by COW was doing something like this:
> >>
> >> ########################################
> >> use strict;
> >> use warnings;
> >>
> >> use Inline C => Config =>
> >> BUILD_NOISY => 1,
> >> USING => 'ParseRegExp';
> >>
> >> use Inline C => <<'EOC';
> >>
> >> void change_char(char * in) {
> >> sprintf(in, "%d", -123);
> >> }
> >>
> >> EOC
> >>
> >> my $orig = 'XOXO';
> >> my $copy = $orig;
> >>
> >> print "$orig $copy\n";
> >>
> >> change_char($orig);
> >>
> >> print "$orig $copy\n";
> >> ########################################
> >>
> >> On 5.18 and earlier, this script outputs:
> >>
> >> XOXO XOXO
> >> -123 XOXO
> >>
> >> But with 5.20, when you call change_char() to alter $orig, it also
> alters
> >> $copy - ie the script outputs:
> >>
> >> XOXO XOXO
> >> -123 -123
> >>
> >> According to p5p, this is a misuse of the char* typemapping, which was
> not
> >> intended to accommodate this type of writing, though the following
> (which
> >> avoids the char* typemapping) does exactly the same thing:
> >>
> >> void change_char(SV * in) {
> >> sprintf(SvPV_nolen(in), "%d", -123);
> >> }
> >>
> >> (No doubt this is also misuse, hidden under another cloak.)
> >>
> >> I think there are API calls one can make to avoid the problem, but I
> ended
> >> up just rewriting my XS code such that whenever an XSub writes to a
> buffer,
> >> it writes to a buffer that was created in XSpace (not a buffer that was
> >> passed to it from Perl-space).
> >>
> >> I think you'll find that any XS/Inline problems you're having with COW
> will
> >> be (in the view of p5p, at least) because the XS code needs to be
> >> rewritten - not because of some problem with COW itself.
> >> But without seeing an actual demo of your problem, I'm only speculating.
> >>
> >> I don't think there should *ever* be a need to make amendments to a C
> >> library - though there may well be situations where the (XS) code that
> >> accesses that library needs to be changed.
> >>
> >> Cheers,
> >> Rob
> >>
> >>
> >
> >
> > _______________________________________________
> > Perldl mailing list
> > [email protected]
> > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
> _______________________________________________
> Perldl mailing list
> [email protected]
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
