Perusing Thread::Queue, I see that it has no XS code and just does

use threads::shared 1.21;
[download]

So replacing that with

use forks::shared 1.21;
[download]

would probably work fine. No, I haven't tested it (neither have you).

You could even do some hackery so that you don't have to edit Thread/Queue.pm... And looking inside the source code for forks::shared I see that this hackery is already done, despite finding no evidence of that in the documentation for forks::shared nor forks.

So you should just try it:

#!/usr/bin/perl -w
use forks;
use forks::shared;
use strict;

use Thread::Queue;
...
[download]

I think this may be evidence:

forks - drop-in replacement for Perl threads using fork()

forks::shared - drop-in replacement for Perl threads::shared with forks()

Since forks overrides core Perl functions, you are *strongly* encouraged to load the forks module before any other Perl modules.

You should be able to run threaded applications unchanged by simply making sure that the "forks" and "forks::shared" modules are loaded, e.g. by specifying them on the command line. Forks is currently API compatible with CPAN threads version 1.53.

I think this may be evidence

That's some lousy evidence, especially when you put it in context of the rest of the documentation.

It is quite clear from the documentation that you can take code that was previously using "use threads;" and change it to code that does "use forks;" and this makes forks.pm a "drop-in replacement" for threads.pm, of course. That doesn't mean "forks.pm does tricks such that a future instance of 'use threads;' won't actually try to load threads.pm but will still export the desired functions, just the forks.pm versions of them instead". You'd think such an unusual bit of "magic" would be worth noting much more explicitly (well, I certainly would -- I'd expect the module author to come close to bragging about it).

The "load the forks module before any other Perl modules" might be a really indirect clue except that the other part of the sentence is "Since forks overrides core Perl functions" not "Since forks will prevent threads.pm from being loaded".

Mix that in with the most prevalent part of the documentation:

use forks;    #ALWAYS LOAD AS FIRST MODULE, if possible
use warnings;

# a bunch more code that never mentions "use threads;"
[download]

Now, "You should be able to run threaded applications unchanged by simply ... specifying [-Mforks] on the command line" is real evidence that I missed (and I suspect the original poster also missed this since it is nearly a direct answer to their question). Of course, it would be easier to understand and easier to notice if it actually said "-Mforks" there.

Going back and searching for cases of "use thread;" and "-Mforks" shows that this stuff is actually documented (though you also appear to have missed most of that documentation since such would have made much better examples of "evidence").

The synopsis actually says

# Use forks as a drop-in replacement for an ithreads application
perl -Mforks -Mforks::shared threadapplication
[download]

Unfortunately, that very short example comes after an entire page of code that was of absolutely no interest to me so I wasn't paying close enough attention by then to notice it. It also doesn't help that an example of a command line is just stuffed into the same code block full of Perl source code. One of my style rules when coding is "short stuff first" and I think that'd help a ton here. Put those two lines first (and probably also separate it from the rest of the synopsis code with a non-code POD paragraph, perhaps simply "or").

And this is another example of the typical case of module authors seeming to be shy to explain their "magic". I'd be happy to see forks explaining that it sets $INC{'threads.pm'} and defines threads::import() to make the magic that much clearer (not just about what it hopes to accomplish but also making it easier to predict those unexpected/undesired consequences).

I'd previously looked at threads and was impressed by it. But this rather important feature still wasn't evident to me after a second casual inspection. I'm confident that I would have discovered this feature if I'd ever had occasion to use the module. But this particular feature should be more obvious in the documentation because I'm much more likely to have a use for the module now that I know about that feature. I shouldn't have to search the documentation to find it (or glance at the source code, where the feature jumps right out at one).

Heh, even some of what looked like clear "evidence" that a subsequent search found:

perl -Mforks  script.pl
perl -Mforks -Mforks::shared  script.pl
[download]

actually isn't "evidence" when you read the nearby text, which explains those examples in quite different terms.

Anyway, I'm even more impressed with forks.pm now. Now all it needs is a portability feature so that 'use forks;' on Win32 [or other platform without a non-simulated fork() implementation] does 'use threads;' instead (unless I also just missed that in the documentation).

- tye        

The parts you bolded just mean they share the same API. By no means does that say forks are used when threads are requested.

For example, CGI::Simple is a drop-in replacement for CGI if you don't use the HTML generation functions, and by no means does CGI::Simple affect use CGI;.