On Fri, 13 May 2005 16:36:05 -0400 Matt Sergeant <[EMAIL PROTECTED]> wrote:
> On 13 May 2005, at 16:12, Matt Sergeant wrote: > > > I'm also wondering if there's a better way to do can_read than going > > back into the event loop... > > Correction to what I wrote in the previous email... There's no other > way to do it than figure out the above... > > The good news is that if I can figure out the above then it'll probably > be a springboard onto other good things too. It seems to me that can_read is a convenience function to allow folks like check_earlytalker to avoid splitting their handlers into top and bottom halves. Could we have a can_read_top that would do the setup and register a callback &code, and a can_read_bottom that would complete the handler? I suspect for that to work, the whole smtp session would have to be turned into a strict state transition table. That would probably mean expanding the definition of "event" to include anything that could cause a state transition. FD activity (as we have now), timed triggers, etc. OTOH, connect handlers are the only immediate problem, so is there a connect-specific solution? Is there some way to initiate them more directly from the event loop? Brian
