Front page | perl.perl5.porters |
Postings from November 1999
On Tue, 16 Nov 1999 09:33:54 EST, Dan Sugalski wrote:
>The following patch provides a new macro, SvLOCK, which lets XS code snag a
>perl-level lock on an arbitrary SV *.
SvLOCK() seems like a bad name. (Compare SvREADONLY() etc.)
>--- sv.h;1 Sat Sep 25 06:25:28 1999
>+++ sv.h Mon Nov 15 12:27:56 1999
>@@ -696,3 +696,19 @@
>
> #define SvGROW(sv,len) (SvLEN(sv) < (len) ? sv_grow(sv,len) : SvPVX(sv))
> #define Sv_Grow sv_grow
>+
>+#ifdef USE_THREADS
>+# define SvLOCK(sv) STMT_START { \
>+ dSP; \
>+ SAVETMPS; \
>+ PUSHMARK(SP); \
>+ XPUSHs(sv); \
>+ PUTBACK; \
>+ Perl_pp_lock(ARGS); \
>+ SPAGAIN; \
>+ PUTBACK; \
>+ FREETMPS; \
>+ } STMT_END
I don't like this much either. Simply make up sv_lock() and
sv_unlock() functions that don't use the stack instead and have
the internals call them. Which means no macro is needed.
>+#else
>+# define SvLOCK(sv)
Must be set to NOOP.
>+#endif
All that said, every time I see people patching USE_THREADS code I
wonder if it's all going to be for nothing. I don't see much hope
for salvaging the existing model of USE_THREADS where prolific
locking is needed.
5.005_63-tobe has a working perl_clone() now. It is able to do
stuff like:
status = perl_parse(my_perl, ...);
if (status) {
new_perl = perl_clone(my_perl, flags);
perl_run(new_perl);
perl_destruct(new_perl);
perl_free(new_perl);
}
perl_clone() can also be called from within the runtime. There's
a stub fork() implementation using that too.
All coming soon to a CPAN near you.
Sarathy
gsar@ActiveState.com