Re: Re: Forks.pm dilemma

[liz]

...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

[Courage]

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

[liz]

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

[Courage]

For sure we were talking apples and oranges.

Initially I thought that you can not use *XS* feature in perl-5.6.1 that was appeared in perl-5.8.0.

Now I see that in perl-5.6.1 there is no way at all to prototype a subroutine that takes a reference to array or hash as its first argument. I checked sources and realized that.

In this case may be source filters could be kind of solution as a hack. But source filter not necessarily installed everywhere.

May be it's better to introduce three prototyped functions for each: share_a, share_s, share_h (for sharing array, scalar and hash respectively)?

Also I did some RTFSing (f=fine here), and now understand a little bit more on situation. Following code is a maximum that I reached on this matter, it finds a prototype for a subroutine:

use B;

sub share(\[@%$]) {print qq/[@_]/}

%stash = B::svref_2object(\%{"::"})->ARRAY;
$c=B::svref_2object(\&share);
#... or this $c=B::svref_2object(\&share);
print 'prototype equals to '. $stash{share}->CV->PV,"\n";

Courage, the Cowardly Dog