develooper Front page | perl.perl5.porters | Postings from May 2013

Re: SV_CHECK_THINKFIRST() needs to be rethought and further COWwoes....

Thread Previous | Thread Next
From:
Tony Cook
Date:
May 10, 2013 07:56
Subject:
Re: SV_CHECK_THINKFIRST() needs to be rethought and further COWwoes....
Message ID:
20130510075612.GG3357@mars.tony.develop-help.com
On Thu, May 09, 2013 at 06:18:19PM +0100, Nicholas Clark wrote:
> XS code that uses C API calls such as sv_setpv(), set_pvn() and similar
> will always work. The problem is that there's this massive grey area about
> how much of the internal representation XS code is permitted to rely on,
> which makes it really difficult to do any sort of significant rearranging
> of the internals, because a lot of code on CPAN makes a lot of assumptions
> about what it's legal to do, and those assumptions have remained unchanged/
> unchallenged in over a decade.
> 
> In turn this comes back to the basic problem that there never was an "API"
> designed. XS has "happened" as a side effect of authors looking at the
> internals and copying bits that worked. And those internals make a lot of
> direct data structure accesses, rather than vectoring through function calls,
> which means that
> 
> 1) the internal data structures are exposed
> 2) it's hard to impossible to intercept accesses and create compatibility
>    veneers
> 
> 
> I'm not anything is wrong or right here. I'm saying that anything is going
> to have to be a compromise, based on guesswork, judgement calls and possibly
> even luck.

So should we provide an API that abstracts access to the buffer so
that modules that want direct access for performance can safely access
it?

Maybe:

/* before I touch the buffer */
char *sv_buffer_lock(sv, size, flags);

SBLf_UTF8 - make the existing buffer UTF-8 (ignored for SBLf_UNINIT)

SBLf_BYTES - make existing buffer bytes (ignored for SBLf_UNINIT)

SBLf_UNINIT - just give me a buffer, I'll only write to it (a debug
perl might fill it with trash)

SBLf_CROAK - croak if SBLf_BYTES can't be honoured.

SBLf_NOMAGIC - don't SvGETMAGIC()

/* I need more space */
char *sv_buffer_grow(sv, size, flags);

valid flags:
SBLf_UNINIT - ignore the existing data

/* I've finished, offset would commonly be 0 */
void sv_buffer_unlock(sv, offset, size, flags);

SBLf_UTF8 - the new data is UTF-8 (ignore the previous flag set)

SBLf_BYTES - the new data is bytes/latin1 (ignore the previous flag set)

SBLf_DISCARD - just make it undef (offset, size ignored)

SBLf_NOMAGIC - don't SvSETMAGIC()

A debugging perl could panic() if SvPVfoo() was called on a buffer
locked SV.

For older perls, ppport.h could provide an implementation.

We might provide variants to avoid complex macros in ppport.h:

  sv_buffer_lock_uninit()
  sv_buffer_unlock_undef()

Tony

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About