Re: exported.writes inside a hook threadlock?

Well, I'm 90% sure about that being the reason we didn't all user output
into the event queue.  I do remember having problems with using just
OutputEvents and with just doing things synchronously and that's why both
exist, but we lean heavily on the synchronously stuff.

If you want to call exported.write* inside of the to_user_hook, you should
enqueue an OutputEvent.  That'll fix the infinite loop issue (sort
of--you could end up with a loop over OutputEvents depending on what
you're doing) though I'm not sure that's a particularly good idea.

/will


On Mon, 12 Apr 2004, will guaraldi wrote:
>
> On Mon, 12 Apr 2004, Eugene wrote:
> >
> > The exported.write_user_data calls engine.writeUI, which, in turn, spams
> > the "to_user_hook". Then your hook catches the spammed call and calls
> > the exported.write_user_data, which calls the engine.writeUI, which in
> > turn, etc. etc.
> >
> > To Will: is there any cause why the engine.writeUI calls the UI module
> > directly, and doesn't shedule the call via it's event queue? At least,
> > the client won't hang.
>
> Well, no one should be calling exported.write* functions from functions
> registered with the to_user_hook.  There's an OutputEvent (I think that's
> what it's called) for spinning output to the user into its own event.  The
> problem with using this is that the output to the user happens after all
> the events prior to the OutputEvent have been handled--so it's serialized
> but out of order in respect to what happened.
>
> /will


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click