Could I invoke Tcl_DoOneEvent in both interpreter without any problem?
Then those interpreters will be running in the same thread.
> they use same event loop or individual event loop?
At any given time, in one thread, at most one event loop may be
processing events.
There might be several nested event loops "running", but only the
innermost is actually processing events and looking for its termination
condition.
> Could I invoke Tcl_DoOneEvent in both interpreter without any problem?
If you produce nested event loops, be aware that the inner loop must
terminate before the outer one can. So long as that's acceptable,
there's no problem.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Don Porter said the following on 8/4/2005 10:20 PM:
Don Porter:
>> If you produce nested event loops, be aware that the inner loop must
>> terminate before the outer one can. So long as that's acceptable,
>> there's no problem.
hahaha wrote:
> Thanks for your answer, how to implement an nested event loop ?
If you call Tcl_DoOneEvent() at a time when another Tcl_DoOneEvent()
is still running, the call you make is nested within the other one.
> Thanks for your answer, how to implement an nested event loop ?
Call [update] while other things are going on? I think the question is
not so much "how do you create a nested event loop" as "what do you
think that creating a nested event loop will accomplish?
That is, what are you really trying to do?
The only way to get a good answer for what you need to do is to explain
what you're trying to do, not what you think you need to do. ;-)
It sounds like you're under the impression that "nested" event loops
will give you concurrence. They won't. They can, under limited
circumstances, give you the illusion of concurrence. Used too
liberally, they can also be almost as big of a headache as separate
threads (with the exception that they are determinate).
Think of event loops and [update] as "cooperative multitasking." Things
will run "at the same time," as long as you speckle your code with
enough calls to [update] (or uses of [after] or [fileevent]) to make it
"seem" like they are running at the same time. If you put in no
opportunities for one bit to sleep, it won't. Managing [update]s can be
fairly easy (e.g. a progress bar), but can, on occasion, be tricky,
because you're trying to "synchronize" events to happen when other
procedures enter their event loops.
If what you want is threads, use threads. If you want determinacy
without locks, at the cost of having to manage "multitasking" yourself,
use event loops.
Incidentally, I would assume, though someone please correct me if I am
wrong, that a single event loop would not take advantage of a MP system,
but threading should?
--
MKS