Areas where Windows Perl has problems

There are some areas where Perl on Windows doesn’t quite work. In some of these, such as forking, that’s because Windows doesn’t work like that. In others, it’s because the code people have created with Perl, isn’t portable.

I’m collecting some of those problems here and will improve on this post as I get feedback. This is more of a scratchpad for future thing than a fleshed-out idea. You can help!

Forking and asynchronous frameworks that fork

Mod_perl, a plugin to embed Perl inside apache, used to be a problem on Windows because apache used to be a problem on Windows. Apache 1.x wanted to fork. Apache 2.x targeted Windows with another concurrent processing module to fix that. perl.apache.org has instructions for Apache 2.x and Perl.

Perl has several asynchronous frameworks, but if they are based on fork, they will have trouble on Windows. If your web framework depends on one of those, it may not work either.

Some things to investigate: Parallel::Prefork, IO::Ascync, EV, Thrall. Does anyone want to do the shootout for those?

3 thoughts on “Areas where Windows Perl has problems”

fork doesn’t ‘work’ but I have used threads and threads::shared with a great deal of success … and I _feel_ that having the ability to account for thread pools is relatively consistent across platforms

I think that one of the big ones is to rely on external programs on Unix-like operating systems. It is particularly annoying when it would be easier to implement the needed functionality in Perl. For example I replaced the use of sed and dc from a program with a simple for loop. ( It still wasn’t portable to Windows, as it is a FreeBSD specific utility )