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

["John E. Davis" <davis@xxxxxxxxxxxxx>]

=?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?

The vast majority of the time jed is waiting for an event from the
keyboard, a subprocess, the mouse (GPM), an X11 event, etc.  One way
to handle this is to busy-loop over all event channels looking to see
if an event is ready.  But that is a bad idea on a multitasking system
because it wastes CPU cycles.  Instead, jed uses the "select" system
call and sleeps until one of the underlying file descriptors has input
available.

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.
--John



--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.