On one hand, overridding CORE::GLOBAL::fork is about the only way you're going to be able to do this. On the other hand, I somehow doubt you're the only person wanting to override fork. And if more than one person wants to override fork in the same process, then something's not going to work.

My suggestion is simply go for it. But provide for alternatives.

I would think of an interface kind of like this: when I use Tie::SharedDB qw(:fork);, I'm asking you to override global fork. That means I assume responsibility for not colliding with anyone else. However, when I don't pass in :fork, I'm then assuming responsibility to call Tie::SharedDB::prefork() and Tie::SharedDB::postfork($rc_from_fork) myself. (The $rc_from_fork gives you the ability to do something different in the child vs the parent in the future.) Your global override, should it be used, would use the prefork/postfork functions internally as well, just to maintain consistent code paths.

At this point, it becomes the user's choice as to which one works for them. For the majority of users, the global override will be sufficient. But for those who have competing global overrides, you provide an option.

The problem with your thoughts on using Sub::Exporter::Lexical is that you end up having to override every module currently available on CPAN and every module that will ever be released on CPAN that uses fork. And that's just nuts. The global override does that for you, more or less, for the vast majority of the cases, while the more-cumbersome prefork/postfork functions allows the user to most likely be able to handle the rest.

Another possibility is to create an external fork module that does the override. Say "Fork::Common" or something, where it registers pre- and post- fork duties. If this module is available (checking eval { require Fork::Common; 1 } would suffice), it would allow you to register your pre/post fork functions with it, and not override the global fork. And then, theoretically, other modules that want to override fork could do likewise, and we'd end up with a single override of CORE::GLOBAL::fork that everyone could share. Of course, this would require other modules that need overrides to switch, but you'd still have your pre/post fork functions available in the meantime.

In reply to Re: To override fork, or not to override fork by Tanktalus
in thread To override fork, or not to override fork by learnedbyerror

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.