Conference bulova::decw_jan-89_to_nov-90

I hate to ask the obvious, but are you polling for more events via XtNextEvent
and dispatching them via XtDispatchEvent, or are you not doing any event
processing at all? You need to periodically poll the event queue to keep things
going...

Kevin

    I do not poll for events. My XtMainloop is supposed to take care of it
    - right ?
    
    I have applications which run in a similar fashion were polling is not
    used. These applications are written in UIL and C using toolkit
    routines.
    
    Some differences between the applications which work and this :
    
    1. No user written AST procs are used in working routines.
    
    2. Application runs after invoking 1) dialog-box 2) pop-up dialog box.
       User inputs are accepted in either kind.
    
    3. There is no intensive I/O activity.
    
    
    The one that that does'nt work is an application to show thruput
    from transferring data from one lat port to another using application
    ports. A QIO read is followed by a QIOW write and then the time for
    the round trip is calculated. During this time I want to display the 
    thruput and go to the next iteration. Theoretically, there is no 
    CPU activity after the QIO write and read completes. I don't understand
    where the problem is. As I said before events are getting queued up
    and are not getting delivered. I am using event flag variables rather
    that pure numbers in  my program.
    
    
    Thanks.
    
    Ramesh
    

    Following is the note I had posted in VMSNOTES conference couple of
    weeks ago. I believe I am seeing the same symptoms - asts are not
    delivered. Based on the reply I thought my DECW should work, but it
    does'nt. Maybe what I am seeing is not entirely a DECW problem.
    
    Any ideas are welcome.
    
    Thanks.
    
    Ramesh
    
    
              <<< VAXWRK::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
           -< VAX/VMS and more.   *** DIGITAL INTERNAL USE ONLY *** >-
================================================================================
Note 1647.0                  ASts are not delivered                    4 replies
CIMNET::SWAMINATHAN                                  21 lines   9-JUN-1989 09:03
--------------------------------------------------------------------------------
    Hi:
    	I have two programs which are identical except for device names.
    The program is supposed to send and receive data through a looback
    on a pair of lat ports. Program 1 loops between port 2 and 3 and
    program 2 loops between 4 and 5 on the DECSERVER.
    
    	In the program I post a QIO read and then do a QIO write. The write
    has no ast associated while the read does. The read and write calls are 
    sequential.
    
    	When I run the two executables concurrently on different windows,
    I find that one of the programs does'nt get its AST delivered for about
    10-15 passes. When it gets its AST delivered, then the other program does'nt
    get its ASTs delivered. Both of them get their ASTs delivered
    concurrently for 3-4 passes.
    
    	 
    My question is can AST's get lost ?
    	
    
    Ramesh
              <<< VAXWRK::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
           -< VAX/VMS and more.   *** DIGITAL INTERNAL USE ONLY *** >-
================================================================================
Note 1647.3                  ASts are not delivered                       3 of 4
STAR::KENNEY                                         11 lines   9-JUN-1989 14:13
                          -< VMS will not loose ASTs >-
--------------------------------------------------------------------------------
    The ASTs will not be lost.
    
    What you are seeing is probably happening because of the way LAT works. 
    LTDRIVER will attempt to take all of the data that it can without
    waiting.  This data will be sent to the server box and back to the
    driver.  Depending upon how the host, and server are loaded you could
    see many wreite requests complete before the read completes and the AST
    is delivered.
    
    
    Forrest

I'm not sure I understand exactly what you are doing. Are you running some
significant amount of synchronous code as part of your callback routine for
the pushbutton activation, or are you simply issusing a QIO (not QIOW) and then
exiting from the callback routine.

When you are in a callback routine, events are not processed until you return
(this is because they are processed by XtMainLoop, which is what actually calls
the callback routine [well, this is a simplification]).

If you are going to spend a long time in your callback routine, you will need
to poll for events yourself, and also do something to eliminate unwanted
re-entrancy (someone pressing your activate pushbutton will cause you to
execute the same callback recursively). Note that during the time that you
are waiting on a QIOW, your interface will not be able to respond at all.
Personally, I try to avoid *all* synchronous I/O in X-oriented applications -
I don't like the application to ever be "out to lunch".

Kevin

    I have async and synch code within my push button activation procedure.
    In fact I stay inside the procedure forever, hoping the user input will
    get me out. From what I understand from your reply is that I should 
    poll for events withing the activation procedure myself and decide to
    stay within or exit the procedure. 
    
    This means that events that happen are not dispatched synchronously
    by XtMainloop's code. One application I know does not exit the
    push button procedure and calls XtAddtimeout whenever it has to
    loop back again. This seems to keep the events to serviced well.
    This trick might also work in my case.
    
    Can you post a sample code fragment to illustrate the event handling
    or send via E-mail ?
    
    Thanks Kevin, you reply really helps.
    
    Ramesh

Unfortunately, the program that I did this in is on a magnetic tape somewhere,
and I haven't had a chance to restore it since I've moved systems...

However... from what you've described, I think that I can give you some
suggestions. There are two toolkit mechanisms which you might want to look
into.

One of them is called "work procedures". A work procedure is a routine which
will be called when the toolkit has no events to process. If you can break
up your routine to execute into small pieces, you can, from your activate
callback, add a work procedure which will do the first part of your operation.
The code for the first operation should execute a little bit of the work,
add the second part as a work procedure, and then exit back to XtMainLoop.
This will allow the toolkit to process your events, and then go back to
your thread of execution. Look into XtAppAddWorkProc for this.

The second thing that you should look into is XtAppAddInput. This routine
allows you to register an event flag with the toolkit, that, when set,
indicates that a routine should be called, as if it were a callback. You
could replace your QIOWs with QIOs, and when your AddInput callback routine
gets called, continue with your thread of execution.

I hope that this helps you.

Kevin

    Thanks Kevin. I will work with your suggestions.
    
    In the meantime if you happen to find the source please mail it or
    post it here.
    
    Thanks.
    
    Ramesh