On Mon, 7 Aug 2000, Jiang Wu wrote:
> > From: Mo DeJong <[EMAIL PROTECTED]>
> >> > java::call AppendEventQueueThread queueVwaitEvent [java::getinterp]
> >>
> >> Note: this will NOT block the C Tcl shell because you are just posting an
> >> event to be executed later. You have to use 'vwait' or 'update'
> >> here to force the event loop to run.
> >
> > The 'java::call AppendEventQueueThread queueVwaitEvent' does that.
>
> No, it does not. When you call AppendEventQueueThread.queueVwaitEvent(), it
> queues an event to the event queue. As a result, immediately after this
> call, the event is only queued to the event queue, but not processed. Are
> we in agreement so far?
>
> > The point it to call vwait from the Notifier dispatch.
>
> This can only happen when the event loop runs to execute event. You can use
> 'vwait' or 'update' to cause the event loop to execute. The C version Tcl
> shell does not run the event loop by default.
You are correct of course. That it what I meant by the "second vwait".
Lets say you used the update command instead, like so:
java::call AppendEventQueueThread queueVwaitEvent [java::getinterp]
update
That will make the shell go to sleep for 10 seconds, with
these results:
orig_numQueued = 0
numQueued = 11
numProcessed = 1
I would expect the numProcessed to be the same as the numQueued.
The other events should get processed while in the vwait, right?
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com