How to make XSUBs thread-safe? xsubpp switches?

I

Ilya Zakharevich

Suppose I have an interface module to an external library with
hundreds (or thousands) of XSUBs, and I want to make it thread-safe.
The external library is not. So what looks like the simplest
first-stage solution is to automatically insert locking code about all
XSUBs. But we already have a preprocessor which massages XSUBs:
xsubpp.

So: is it possible to instruct xsubpp to insert locking code about
all/selected XSUBs? At least the docs of perl-5.8.8 one do not
mention anything like this...

Thanks,
Ilya
 
I

Ilya Zakharevich

I don't think so. It's not even clear what should be locked: the
ithreads locking code only allows you to lock a shared variable, so the
5005threads solution of locking the CV doesn't work any more.

As far as I can see, this makes only locking of BOOT problematic.
Other XSUBs would lock local_XSUB_lock_shared_SV. It would be a
function of BOOT to initialize this SV*.

So one would need to manually instrument BOOT only, the rest could be
done (inefficiently but) automatically...

For best result, one would have "global" switches like

AUTOLOCK_ALL: local_XSUB_lock_shared_SV

and an attribute

AUTOLOCK: local_XSUB_lock_shared_SV
AUTOLOCK: 0

for individual XSUBs...

Ilya
 
I

Ilya Zakharevich

Well, you can get the latter with

SCOPE: ENABLE
PREINIT:
dMY_CXT;
INIT:
SvLOCK(MY_CXT.locksv);

plus appropriate logic in BOOT and CLONE.

And where the unlocking would happen? Or would dMY_CXT somehow
magically define something which unlocks on return? And if it is so
magical, why not make things which auto-SvLOCK inside dMY_CXT? Or
would it be then MY_dMY_CXT ;-] ?

Puzzled,
Ilya
 
I

Ilya Zakharevich

Mmm, I like this idea.


What does REMOVE_ALL do for you? Change the default for XSUBS declared
after this? I'm not sure how easy it would be to use this, in general;
how would you reliably identify which bits to remove? Re-specify them in
full? What if you start with

GLOBAL_INIT_ADD:
FOO();
BAR();
BAZ();

and you later want to remove just the BAR?

I see that we think similarly. ;-) For a few hours now I think in
terms of "keys". A key is a Perl symbol. To a key one associates a
sequence of "actions" to perform. This may look almost exactly as a
defintion of an XSUB:

KEY=lock1
PREINIT: dMY_CTX;
INIT: SvLOCK(MY_CXT.locksv);

Such a definition does not change how following XSUBs is processed.
However, at any moment one can change the list of "active keys":

KEYS: lock1 croak_on_false
KEYS: -lock1
KEYS: +lock1

(either in global scope, or inside an XSUB.
Possibly better would be PREPEND: and APPEND: instead of simply GLOBAL:,
in case it matters whether the section is added before or after the
XSUB's own section.

Hmm, this may be solved by insertion of

KEY=XSUB

in the (ordered) list of keys. (This must have no "actions"
specified, but would separate "prepend" actions from "append" ones.)

Thanks,
Ilya
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,051
Latest member
CarleyMcCr

Latest Threads

Top