- Subject: Re: internal: Why X events handled in *key* functions?
- From: Jörg Sommer <joerg@xxxxxxxxxxxx>
- Date: Tue, 29 May 2007 15:06:03 +0000 (UTC)
Hello John,
"John E. Davis" <davis@xxxxxxxxxxxxx> wrote:
> =?UTF-8?Q?J=C3=B6rg?= Sommer <joerg@xxxxxxxxxxxx> wrote:
>>I don't see why you handle the X events and the sub processes in
>>functions like sys_input_pending() called by sys_getkey(). Why they
>>aren't handled in do_jed()? Do you have a document (except the code) that
>>describes such internal structures?
>
> I put the call to "select" in the "getkey" function because I felt
> that in a single threaded application, this would be the most
> strategic place for that call. Consider this contrived example:
>
> define silly ()
> {
> flush ("Press any key when you want to contine");
> () = getkey ();
> }
>
> If you run this with Xjed, you will find that X11 events will contine
> to get processed by jed. Moreover, the time displayed on the status
> line will continue to be updated, subprocess input handled, etc. All
> of this happens because that call to select is in the getkey function.
>
> I hope this sheds some light into this process.
Yes, this enlightened me and now, I see much better what's going on.
Is it possible to suspend a call in SLang, e.g. save the context of a
getkey() and reload it when a key is available? What happens if I do a
sleep or a connect with the new socket engine? How does SLang handle such
blocking calls—I think there are much more?
Thanks, Jörg.
--
“Politics is for the moment, equations are forever”
(Albert Einstein)
--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.
[2007 date index]
[2007 thread index]
[Thread Prev] [Thread Next]
[Date Prev] [Date Next]