`enqueue-eval-event' problem

[Zajcev Evgeny]

Hrvoje Niksic <hniksic at xemacs.org> writes:

> Zajcev Evgeny <zevlg at yandex.ru> writes:
>
>>> Does `(sit-for 0)' [force event loop drain] as well?  That's BTW
>>> the standard kludgy way to force redisplay.
>>
>> Yes, you are right, `(sit-for 0)' does the trick too!  Should I
>> consider such events behaviour as bug or implementation peculiarity?
>
> I think it depends on what your code was doing.  Your first post
> didn't make it clear whether you returned to the event loop after
> dispatching the event, or you just kept running Lisp?  Since XEmacs is
> not multi-threaded, the event loop has to be reached in order for the
> event queue to get drained, and `(sit-for 0)' is as good a way as any
> (although one might wish for something less kludgy and better
> documented!)

I will describle why i'm using `enqueue-eval-event'.  I've got network
connection filter, which reads some data and according to it generates
events to be processed lately, it can't be acomplished inside filter
function because event dispatcher may need to performe some i/o,
i.e. run `sit-for' or `accept-process-output'.  Events occurs pretty
frequently, about 1-100 events per second.  In situation when XEmacs
stops dispatching eval events it surely in waiting state, i.e.  not
runnig lisp, because if i press some key or button it reacts
immeditely, also gnuclient runs immediately without any blockage and
only after such action my eval events dispatches.

What is the most interesting that if using `(redisplay-echo-area)' as
kludge instead of `(sit-for 0)' eval events executions performes much
more faster!  With `(redisplay-echo-area)' i can execute about 200
eval events per second without any noticable lags, but `(sit-for 0)'
causes xemacs to eat more cpu and to lag.

That things i use in xlib package.  Earlier xlib had its own events
mechansm, with events execution protections, and stuff, but the
implementation leakage was that X events dispatches inside process
filter and X event dispatcher ofter need to performe i/o, for example
fetch some info about X window.  Mostly it works, but sometimes causes
very strange things.  So we decided to use native xemacs events
machanism to prevent possible bugs ..

>
> However, you also wrote:
>
>     I surmise that this is because, in moment when you enqueue eval
>     event xemacs is under next-event loop, waiting for some certain
>     event to occur and _skiping_ other events(i.e. not calling
>     `dispatch-event'), [...] if my 'eval events are skiped, they will
>     never be dispatched,
>
> I don't think XEmacs should ever just "skip" events -- if it does, to
> me it sounds like a bug.  Can you construct a minimal test case for
> the code that sets up an event that gets skipped in this fashion?

Yes i can do little test:

    ;; Start timer, to message us every second
    (defun myfun (&rest args)
      (if (boundp 'myval)
          (setq myval (+ 1 myval))
        (setq myval 0))
      (message (format "myval=%d" myval)))
    
    (setq mt (add-timeout 1 'myfun nil 1))
    
    ;; Create annotation
    (make-annotation xemacs-logo nil nil nil t nil t)
    
    ;;; You still see messages in minibuffer, but press button1 on xemacs logo
    ;;; image and hold it.  No messages, no `myval' increase.  Than release
    ;;; button1 ..

    ;; Stop timer
    (disable-timeout mt)

It can be a bug or not, i dont know.  However i'm very sure that
annotation stuff does not affect in my case, because my eval events
dispatches(not skiped) but lately ..

-- 
lg