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

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

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