Conference bulova::decw_jan-89_to_nov-90

              
    You might try using XSelectAsyncInput to declare a temporary
    handler while this db query is going on. 
    
    Bracket the db query as follows:
    
    XSelectAsyncInput(dpy....dpy,w,mask,proc,data); /*declares handler */
    .
    ....db query
    .
    .                                             
    XSelectAsyncInput(dpy,w,mask,NULL,NULL); /* undeclares handler */

    Here is an async handler that checks the queue for expose events...

    async_event()
    {
        int  remaining;
        XEvent ret_event;
        XExposeEvent *event;

        remaining = XPending(dpy);
        while (XCheckMaskEvent(dpy,ExposureMask,&ret_event) == True)
        {
            event = (XExposeEvent *) &ret_event;
            printf("Queued Expose Event - win %x area %d x %d, %dining\n",
            event->window,event->width,event->height,remaining);
        }
        XSync(dpy,True);
    }
    
    Using XSelectAsyncInput has worked for me sometimes. If your handler is 
    reached your events will be handled asyncronously. However, I have not 
    always had good luck with this. If your handler doesn't get reached you'll 
    get a message of the following sort (if you are using dbx):
    
         I/O possible [select.select:18 +0x8,0x468bd8]
    
    The XUI Xlib Programmer Guide describes this routine (albeit very
    briefly and with several typos). This is not an MIT Xlib call, so
    it won't be found on portable X software.    

    It would be nice if there was some way to let the server know not
    to send events. If I'm not mistaken there was a debate on this 
    elsewhere in this conference...
    

RE .1

>   It would be nice if there was some way to let the server know not
>    to send events. If I'm not mistaken there was a debate on this 
>    elsewhere in this conference...

I thought XPutBackEvent allows an application to tell the server
to postpone event processing. It copies the contents of XEvent
and places it at the head of a waiting Xlib queue.

An XPutBackEvent structure looks like this.

Display *display;
Xevent event;
..
...
XPutBackEvent (display, &event);

I have been told my some X developers that, "event compression" is
another good technique to reduce event traffic.  And much of this
stuff is user-written.  (I have never written my own..so all this
is hear-say!).   It based on the assumption that an application
developer will write application-specific code to reduce or ignore
redundant X events.
I checked my text, and I found some Xlib calls that you may find
useful in doing "event compression".

XPeekEvent, XCheckWindowEvent, XCheckTypedWindowEvent, XCheckMaskEvent,
XCheckTypedEvent, XWindowEvent, XMaskEvent, XCheckIfEvent, XPeekIfEvent,
XIfEvent.

XPeekEvent looks interesting because it allows you to look/read ahead
in the event queue. Slightly different from XNextEvent because it
lets you see what is at the top of the event queue *without removing*
the event from the queue.  Now, it is easy to see how application-specific
code can be written to demarcate what applications get dispatched from the
queue.

Question:
Does the DECwindows toolkit or UIL/DRM/DWIGEN use event compression?
It looks like like an obvious choice to me...no?

Disclaimer:  I am not an X/DECwindows developer..just a user.

Kris..

For most widgets, the XUI Toolkit does mouse motion event compression.  The
catch is, to do compression, you have to be somewhere in the Toolkit's event
dispatching routines.  If the application has gone off on its own for a long
stint of computing, without calling the Toolkit event dispatcher, all bets are
off.

--PSW

    Put back even has no contact with the server.  It only puts an event
    back into the client's queue.  The server keeps on pumping.
    
    If there is absolutely no event traffic while the database querry is
    going on, there will be no server timeout.  There is no "keep alive"
    function other than what DECnet itself does, and that is unaffected by
    the client's actions.  There can only be two possibilities, I think.
    One is that there really ARE events coming, and the other is that
    something unrelated to the server timeouts that have been discussed
    before.   Your description really sounds like the first issue, though.
    
    Burns
    

    If you have access to the sources to the DECwindows interface you could
    make the DB query run in another process.  One process sleeps and
    waits for DB queries to do while the other maintains the user
    interface.  The user interface wakes up the DB query process and
    passes it a query to do before going back to process  X events.  The
    DB query process sets an event flag to inform the UI process of a
    query completion via a XtAddInput callback.

    					MJC

    Hmmm.  Unfortunately, there's no way to  get to the DB call - it's
    imbedded in the 3rd party application.
    
    There's no way to lengthen or flush the queue?  A stopgap measure
    will do for the moment.
    
    - John

Although you might be able to separate the UI and the application, this may
not always be practical or desirable. The increased resource consumption may 
be too much for the given system to handle. We really need a fully reenterant
non-blocking toolkit and Xlib but I guess we'll have to wait until CMA is a
reality. Ideally, the database and UI processing would run as different threads
in the same process.

James

    re .7 (threads)
    And thats about the only advantage of presentation manager over
    X11...
    malcolm

Malcolm,

isn't threads more of an operating system functionality, as far as PM goes?

Kris..

    Tis indeed true that threads is part of OS/2 but since you can't
    buy OS/2 without PM now (though you could once) its kind of immaterial.
    
    malcolm

re:                       <<< Note 1078.6 by SELECT::WIKOFF >>>
                              -< Any ugly fixes? >-

What about lengthening the server retry period via the logical 
names DECW$SERVER_RETRY_WRITE_MIN and _MAX?

At the expense of hanging the server, and of probably doing
ugly things if there really are events and the buffers fill
up, you might try this.

>What about lengthening the server retry period via the logical 
>names DECW$SERVER_RETRY_WRITE_MIN and _MAX?
    
    Will this work?  If it will, then where are these logicals documented? 
    If they are not documented, then what values do the logicals get
    assigned?
    
    Also, is this problem fixed in V2.0?
    
    Thanks for any responses.
    
    scott

The problem is fixed in DECwindows V2.
It is not documented.  See note 197 for more information.

Have some more information.  When we open a terminal window and let it go into
LEF state and run an image that is calling out to 3rd party stuff (NEXPERT).
the application's windows get blown away while it is still running.  If he is
fast enough and clicks in the window and either prevents it from getting into
LEF state, or takes it out of LEF state, this does not happen. 

Does this sound like a known problem with DECWindows, or is it a new, unknown
problem? I had him try the possible workarounds mentioned in here and that did
not make a difference.  He is running DECWindows 2.0. 

Any ideas or suggestions? 

Thanks for any replies. 

scott 

    DECwindows V2 fixes several problems where clients were prematurely
    disconnected when the server/transport detected that the client was
    not responding. However, if the client is genuinely not listening
    to the server, there can still come a point where the server has
    filled all the buffers it has for that client at the client still 
    isn't responding. If that happens, the server will disconnect the
    link to the client.  
    
    I do not understand what you mean by "if the user clicks in the
    window and prevents it from getting into LEF state ... this does
    not happen". Perhaps the client isn't looking for the right events
    until after it gets the first server event? Is the client calling
    out the 3rd party stuff at normal user level or at AST level?