How to make XSUBs thread-safe? xsubpp switches?

Discussion in 'Perl Misc' started by Ilya Zakharevich, Oct 11, 2010.

  1. 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
     
    Ilya Zakharevich, Oct 11, 2010
    #1
    1. Advertising

  2. On 2010-10-12, Ben Morrow <> wrote:
    >
    > Quoth 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...

    >
    > 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
     
    Ilya Zakharevich, Oct 12, 2010
    #2
    1. Advertising

  3. On 2010-10-13, Ben Morrow <> wrote:
    >> 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...


    > 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
     
    Ilya Zakharevich, Oct 13, 2010
    #3
  4. On 2010-10-13, Ben Morrow <> wrote:
    >> GLOBAL_INIT_ADD:
    >> SvLOCK(MY_CXT.locksv);

    >
    > Mmm, I like this idea.
    >
    >> and corresponding _REMOVE and _REMOVE_ALL flavors. Too many...

    >
    > 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
     
    Ilya Zakharevich, Oct 14, 2010
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Francis Reed
    Replies:
    2
    Views:
    743
    Erik Funkenbusch
    Apr 8, 2006
  2. Irmen de Jong
    Replies:
    5
    Views:
    396
    Irmen de Jong
    Sep 28, 2004
  3. Richard Siderits
    Replies:
    2
    Views:
    712
  4. Gabriel Rossetti
    Replies:
    0
    Views:
    1,394
    Gabriel Rossetti
    Aug 29, 2008
  5. John Nagle
    Replies:
    5
    Views:
    509
    John Nagle
    Mar 12, 2012
Loading...

Share This Page