Re: fork & END

[xdg]

Regarding your afterthought: I don't really like END blocks, particularly for modules, because they create another form of the "action at a distance" problem. I would prefer that any module that relies on them say so explictly and with appropriate warnings. I know they are useful in some cases -- but they can easily create problems for downstream users, as you've discovered.

The other thing you asked about is fork. Anytime one is trying to do concurrency, whether forks or threads, a whole host of new concerns inevitably arise. I think it's very important to think through exactly what side effects might arise through concurrency, particularly around cleanup/teardown code. END blocks are just one example. What about object destructors? Assuming that one is finished with some resource is one thread/process may or may not be OK depending on the nature of the cleanup. It may be useful to store $$ in BEGIN as a way of limiting destruction action to the parent process/thread, but it may also be useless in many cases.

Ultimately, I think END should be an infrequent tool, but I think that the onus is on those forking/threading to anticipate side effects and code to prevent them. What makes END so insidious is that one can't defuse it, whereas one could always wrap a misbehaving DESTROY method to call the original only if it has been called from within the parent process.