Joost has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

I am currently working on a set of XS modules for working with LADSPA plugins and so far everything is going allright. (I used Inline::C for prototyping, and that made it quite easy to get stuff working fast.)

However, in the long run I will probably want to make use of ithreads as my 5-year plan is to write a sort of 'virtual studio' type application which will do realtime DSP in C/XS, with a Perl front-end for interfacing with the user.

If needed I probably could try other ways of achieving my goals, but to my eyes a threaded implementation seems natural.

I'm trying to find out how much hairyness I will run into when writing multithreaded XS modules. I haven't been able to find much information on this subject (another case of Warnock's Dilemma). So I'm wondering:

Is there any information on using ithreads in XS, and if not is it because it's too hard or very simple? :-)

Joost. 

-- 
#!/usr/bin/perl -np
BEGIN{@ARGV=$0}s(^([^=].*)|=)()s;
=Just another perl hacker\

[download]

Replies are listed 'Best First'.
Re: Ithreads and XS information wanted
by djantzen (Priest) on May 21, 2003 at 02:06 UTC

    Disclaimer: I don't know XS, but since no one else has said anything ... :)

    <speculation> ithreads work at a level above any multithreading at the C level. An ithread looks a lot more like a process than, say, a Java thread, and each thread contains it's own copy of the all the data in the perl process, sharing entities only explicitly. So I think that each ithread utilizing a module wrapping an XS engine will possess it's own copy of the module in memory. If that's the case, then XS code needn't worry about threading in the perl process. </speculation>

    "The dead do not recognize context" -- Kai, Lexx
[reply]

      I believe XS is a weak point in ithreads. ithreads is able to separate data completely at the Perl interpreter level. It is not able to go below this level.

      XS code needs to be intimately aware of threading, however it may not need to be explicitly aware.

      What I mean by 'intimately aware' is that the designer should review each section of code in the context of an ithread environment to ensure that it will work as expected.

      As long as XS code only allocates its own data structures each time it is invoked (no 'static' or global variables), and only changes data passed in using the official Perl API, XS code will function propertly under an ithreads environment.

      If the XS code needs to keep static or global data it either needs to ensure that the data is initialized only once and only read later, or it needs to access the data within the context of a lock (mutex, etc.). A third option is that the XS code could use thread-specific data.

[reply]
        First off, thanks for your replies.

        As long as XS code only allocates its own data structures each time it is invoked (no 'static' or global variables), and only changes data passed in using the official Perl API, XS code will function propertly under an ithreads environment.

        So that means that C static variables are shared, but I can use perl variables in the normal way, right? Are there any specific issues with accessing :shared perl variables from XS?

        Joost 

        -- 
#!/usr/bin/perl -np
BEGIN{@ARGV=$0}s(^([^=].*)|=)()s;
=Just another perl hacker\

        [download]
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom