|
Home > Archive > Perlbal > March 2007 > Doing IO in hooks? Continuations wanted!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Doing IO in hooks? Continuations wanted!
|
|
| Brian Brunswick 2007-03-05, 7:12 pm |
| 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@forbidden.co. uk__Video_Software_Architect____Disclaim
er
| |
| Brad Fitzpatrick 2007-03-05, 7:12 pm |
| 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@forbidden.co. uk__Video_Software_Architect____Disclaim
er
>
>
|
|
|
|
|