jed-users mailing list

[2007 Date Index] [2007 Thread Index] [Other years]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]

Re: internal: Why X events handled in *key* functions?


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]