Re: Magic-v2, Clone, and a possible `sv_clone` API function

[email protected] ("Paul \"LeoNerd\" Evans") Thu, 11 Jun 2026 13:14:31 +0100
Newsgroups perl.perl5.porters
Message-ID <[email protected]>
On Fri, 5 Jun 2026 17:25:05 +0100
"Paul \"LeoNerd\" Evans" <[email protected]> wrote:

> On Fri, 5 Jun 2026 18:17:55 +0200
> Leon Timmermans <[email protected]> wrote:
> 
> > I can't help noticing that this sv_clone is almost the same thing as
> > sv_dup (or probably sv_dup_inc), except that the new value doesn't
> > live in a different interpreter.  
> 
> Yes indeed - I was thinking that a suitable implementation would
> probably adjust the way that sv_dup works so that the same internals
> could handle both cases, and then be exposed as `sv_clone` as an API
> function, and also used internally by the thread cloning behaviour.

The more I think about it, the more I think that Linux's `clone(2)`
function is quite a similar thing here, and might lend us a few tricks.

In particular, clone(2) takes a bitmask set of flags, where each flag
controls various bits of the cloning operation, in terms of whether you
get a new copy of something like the filesystem space, the mountpoints,
the networking stack, etc... or just a reference to the parent's one.
There's then a particular set of flags that correspond to `fork()`,
and another set for `vfork()`, but if you want something weird you can
call it directly with your own set of flags.

I could imagine us having something similar:

    SV *sv_clone(SV *sv, U32 flags, CLONE_PARAMS *param);

with a particular set of flag constants that the thread cloning
behaviour of `sv_dup()` would call, but by using other sets of flags
you could get the behaviour that the Clone module wanted, or even the
other Clone-Closure module that I discovered the other day... It seems
there's enough variations on the required behaviour to warrant it.

I also suspect that we should aim to fold the various bits of
`cv_clone()` behaviour into it, with some more flags. Two of my modules
(Future::AsyncAwait and Object::Pad) have internal near-copies of perl's
cv_clone() because they want to do something subtly different each
time. Those differences ought to be expressed with more flags and then
I wouldn't have to copy-and-edit core perl code either.

-- 
Paul "LeoNerd" Evans

[email protected]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS