in reply to Ithreads and XS information wanted

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

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

    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]

        Always follow the API. Specifically this means that you should respect get magic before fetching the value of a variable and set magic after storing a value. get and set magic is used to push shared data back and forth between an interpreter allocated only to hold shared data.

[reply]

In Section Seekers of Perl Wisdom