Doing IO in hooks? Continuations wanted!

Brian Brunswick brian.brunswick+perlbal at
Mon Mar 5 19:32:31 UTC 2007

I'm trying to write a plugin that wants to choose an alternate way of serving a file
from a web service, but only depending on the presence on something in the filesystem.

This means that the eg start_serve_request may need to do io before it can
take the decision as to whether to take over the request. But this io should (of course)
be asynchronous. Unfortunately, the existing hooks expect a direct return 0 or 1, instead
of a later continuation with the decision.

It occurs to be that perhaps 'morally' all hooks should in fact pass in continuations,
instead of expecting return values. This would be quite easy to maintain backward compatibility
with the old hook API, by adding new add-a-hook functions and keeping the old ones as wrappers.

Has anyone already done this?

Would it be a good idea? What about performance of creating perl continuations?

Any other solutions to the problem?

Is it generally accepted at perlbal's current level of development to just add in additional hook
functionality that is missing, or are there particular reasons or vested interests in the absence of some things?

If I didn't go the whole hog of splitting all the hooks, I'd need to split up serve_request
to gain access to the middle entry point of it after the async IO with the replacement file name.

Thanks in advance for any help, and thanks for perlbal!

Brian_Brunswick__bdb at

More information about the perlbal mailing list