in reply to Forks.pm dilemma

Option 4 - have share() be a Perl subroutine that determines if the version of Perl is 5.6 or 5.8. If it's 5.6, takes the reference. Then, passes whatever to the XS routine. When building the XS routine, determine the Perl version and build with or without the prototype.

In other words, make your stuff smart so the user can be dumb. :-)

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: Forks.pm dilemma
by liz (Monsignor) on Aug 07, 2003 at 16:24 UTC
    ...In other words, make your stuff smart so the user can be dumb. :-)

    Unfortunately, apart from the technical difficulties (I would appreciate it if someone could tell me how to make the PROTOTYPE: conditional in the XS code, depending on the perl version), this does not address the source incompatibility issue with the real threads module. It's not just about share(), it's also about lock(), cond_wait(), cond_signal() and cond_broadcast().

    I don't see forks.pm as a substitute for the real threads module, just as a teaching and prototyping tool. I would like people to be able to try threaded programming by just downloading a CPAN module, rather than having to upgrade/rebuild perl. I would like the source incompatibility issue to be as small as possible.

    That's why I'm considering the last option as the most favorable: if you want to try out threads programming in 5.6.x, then you know you will have to change your code when you upgrade to 5.8.x and/or real threads. If you want to try out threads programming in (unthreaded) 5.8.x, then you won't need to change anything when you upgrade. So, 5.6.x support is for really toying around, higher perls support a real upgrade path.

    Liz

[reply]
      As I understand this problem, dragonchild actually proposed a solution that actually solves your problem, but you somehow overlooked that.

      Consider: you'll define functions in XS with some changed name (use some prefix for example), without PROTOTYPE keyword and then provide prototype in forks.pm, and those wrapper functions will call proper XS function.
      Why this will not work in your case?

      I did same thing for Tcl perl module, where I solved another problem this way: it was too complicated for me to do logic in XS, so I decided to move it to Perl side.

      I'm not knowledgable enough to say you how to do a PROTOTYPE in perl-5.6.x

      Courage, the Cowardly Dog

[reply]
        I have no doubt that is possible. To an extent, this is already done in threads.pm (because different subroutines are "imported" depending on whether you are using a threaded or an unthreaded perl).

        But this doesn't solve the migration path problem! Code written with the 5.6.x version of forks.pm won't work in 5.8.x without change. I'm trying to find a solution that will allow a smooth upgrade path, so that code does not have to be changed. I believe using a source filter when running in 5.6.x will solve this problem. I'm working on that this weekend. Hopefully there'll be an update again to the original node when it's uploaded to CPAN.

        Liz

[reply]

In Section Meditations