[Prev][Next][Index][Thread]

Re: functionality of HTEventRequestTerminate



In message <199601240043.QAA06873@wally.cs.washington.edu>, Erik Selberg writes
:
>Henrik Frystyk Nielsen writes:
>
>>> I've been digging around in the source, and so far I've been unable to
>>> come up with anything resembling what I need --- which is some
>>> callback / flag / thingy which, upon successfully loading a URL, quits
>>> the HTEvent_Loop.
>
>Here's one better, which I think may work. Currently, HTEvent_Loop
>looks something like:
>
>do {
>
>} while (1);
>
>Can this be changed to:
>
>typedef int HTEventLoopTerminateFunc();
>
>PRIVATE HTEventLoopTerminateFunc *tf;
>
>...
>
>do {
>
>} while (!tf || *tf());
>
>
>There would be some HTEventLoop_setTerminationFunc() call which would
>set the term func. This would just be a function which wouldn't take
>any arguments, or perhaps a request, and would specify whether or not
>to terminate. Yes, it'll probably rely on a global variable somewhere,
>but I think that's OK for the use (and thread-minded people can always
>throw in a mutex).

I suggest the design used in the ILU runtime:

from $ILU/src/runtime/kernel/iluxport.h:
/* $Id: iluxport.h,v 1.116 1995/02/23 23:01:08 spreitze Exp $ */
/* Last edited by Mike Spreitzer February 23, 1995 2:42 pm PST */

/* ================ Concurrent I/O routines ================ */

/*Main Invariant holds; L1, L2 otherwise unconstrained*/
_FN_DECL(void ilu_RunMainLoop, (int *stop) );
/* A single-threaded runtime calls this to animate all true servers, handle the alarm, and do any other registered input processing.  A multi-threaded runtime never calls this procedure, instead forking threads to animate servers and pass the time.  This procedure may be invoked recursively, so long as no two cuncurrent invocations are given the address for "stop".  This procedure processes input and time until ilu_ExitMainLoop is invoked on stop. */

/*L1, L2, Main unconstrained; synch provided by single-threadedness*/

_FN_DECL(void ilu_ExitMainLoop, (int *stop) );
/* This causes the current invocation of ilu_RunMainLoop on stop to return once it's done with the input handler or alarm it's currently executing. */


References: