Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!swrinde!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: Combining event driven and object orient programming Message-ID: Date: 5 Oct 89 17:14:59 GMT References: <13928@well.UUCP> <13929@well.UUCP> Sender: davidm@cimshop.UUCP Distribution: all Organization: Consilium Inc., Mountain View, California. Lines: 37 In-reply-to: nagle@well.UUCP's message of 4 Oct 89 06:48:55 GMT In article <13929@well.UUCP> nagle@well.UUCP (John Nagle) writes: > With a language like C++, there is the potential to have a lot of > bookkeeping taken care of automatically as objects are created and then > destroyed as scopes are exited. Unfortunately, in event-driven > single-thread programs, you can't do this, because essentially all context > associated with where control is in the program (basically, the information > on the stack) is lost every time you go back to the top of the event loop. > Isn't one possibility to not lose the context by calling the event loop instead of returning to it? This may require a little rearranging of callback routines because the new context (the sub-event loop) shouldn't handle all the normal callbacks, just those that make sense in the new context. If the event loop (or event handler) is treated like an object (with static memory areas), there should be no problem in constructing a new event loop. Right? > In principle, if one has cheap multitasking (called, variously, > "threads", "lightweight processes", or "weak fork"), an elegant solution is > for events which will require processing beyond the current event to fork > off a new task to handle them, requesting that related events be forwarded > to that task. The task can have lots of context, and lots of "auto" > storage-class (in the C sense) objects. > The question I have hear is not so much "buying" into the cheap multitasking (or even sub-event processing), but rather the manner of getting out of it when the subtask is done. Is there a return value from this other task or does the task signal its parent with a new event? Assume that the reason for invoking the other task was to get information from another "process" (user, database, whatever) and construct an object from that information that the current task can work with. What should be the method of giving this object back to the parent task? > Now how do we get multithread C++? > One naive question, though. Define "smart" dispatcher? David Masterson uunet!cimshop!davidm