Re^2: Testing for a module's presence

(Ignoring the typo of missing the 'n' in my alias ;->)

While fork can work great on Unix, it's not quite so great on other platforms. EMX on OS/2 (and maybe Win32) handles fork - but it's not really faster. I doubt ActiveState or Cygwin perls handle it (if either do, it'll be Cygwin). So you've simply hit another gotcha: cross-platform compatability. (Traversing @INC and using File::Spec is fast, tight on memory, and completely cross-platform!)

Even on Unix, fork may not be that great. Imagine an embedded perl. The main process (the embedder) has some cleanup in an atexit() in C. That cleanup may include committing or rolling back transactions, deleting temporary files that were in use, or other such behaviour. When you fork, and then the child exits, the atexit handler kicks in and does something like this - and now the parent process is going to be in a wierd place that is going to be really painful to debug. Especially if this ends up on a user's machine and the user imported your module. The C developer has no idea what is causing it, the perl user has no idea, and you're not really involved. Dangerous!

Fork is a dangerous tool - although it can be useful, you have to be really really careful of when you use it, and how you use it. Let's just stick to searching @INC. It's fewer lines of code, too ;-}

Comment on Re^2: Testing for a module's presence

Replies are listed 'Best First'.
Re^3: Testing for a module's presence by sgifford (Prior) on Feb 07, 2005 at 04:45 UTC
The thing I don't like about searching `@INC` is that it's re-implementing a part of Perl based on how it works right now. A future version of Perl could use a different scheme for locating libraries. For example, it could add a new type of arch directory, hash the directories to avoid too many modules in the same directory, add a new `.pmz` type for compressed modules on disk-poor systems, or load code across the network. A user could even provide their own copy of the `lib` module and/or the `require` function to implement those sorts of things right now. In the face of possible changes to the module search algorithm, actually asking Perl to find the library and say whether it worked or not will always work, while re-implementing the library search yourself will only work for as long as nothing changes. Using a module designed to do this, as others have suggested here, is a good compromise. As for the cross-platform concerns, I have used `fork` on ActiveState Windows; it seems like a lot would break without a working copy of this function. And `POSIX::_exit` seems to avoid your other concerns. Also, to clarify, I don't think using `fork` will be particularly fast; just faster than using `system`, which was my original proposal.	[reply] [d/l] [select]
Re^4: Testing for a module's presence by nothingmuch (Priest) on Feb 10, 2005 at 10:12 UTC
Or maybe add support for code refs in @INC... ;-) I'm even using this in Devel::FIXME. Fun fun fun! -nuffin zz zZ Z Z #!perl	[reply]
Re^3: Testing for a module's presence by Anonymous Monk on Feb 08, 2005 at 05:13 UTC
As my sister comment mentions, ActiveState has some support for fork(). In my experience, only a few obscure things don't work. But: `% perldoc perlfork ... AUTHOR Support for concurrent interpreters and the fork() emulation wa +s implemented by ActiveState, with funding from Microsoft Corporation +. This document is authored and maintained by Gurusamy Sarathy <. +.@activestate.com>. ...` [download]	[reply] [d/l]


Syntactic Confectionery Delight
	PerlMonks