Doing IO in hooks? Continuations wanted!

[Brad Fitzpatrick]

This is the direction we took with DJabberd, our XMPP/Jabber server, but
Perlbal still has a lot of legacy hook-must-return-a-value-now stuff.

Non-intrusive patches welcome.  Perhaps a parallel hook with different
semantics, keeping the existing one(s) unchanged?


On Mon, 5 Mar 2007, Brian Brunswick wrote:

> 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 forbidden.co.uk__Video_Software_Architect____Disclaimer
>
>