[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1260.0. "Work Procedures" by AITG::SCALA () Thu Aug 10 1989 18:00

    
    We are adding a DECwindows interface to a Digital product and need to
    be able to continually process user events while running a compute
    intensive portion of code.  We are thinking about using work procedures 
    for the syncronization between our application and the DECwindows event 
    loop as we need a platform independent method of syncronization.
    
    If there are other places in this notes file where work procedures are
    discussed or if you know an alternative method for syncronization with
    less overhead please let me know. 
    
    Thanks a lot. 
    
    Sue
    

T.RTitleUserPersonal
Name
DateLines
1260.1PSW::WINALSKIMeetings are our most important productFri Aug 11 1989 15:0817
(1) Use VAX Ada and do all DECwindows work from one task.  Advantage: very low
    overhead.  Disadvantage:  your application has to be written in Ada.

(2) Use work procedures.  Advantage:  low overhead.  Disadvantage:  your work
    has to be broken into little chunks so that X events get dispatched in a
    timely fashion.  Also, your program can wind up busy-waiting if you forget
    to deassign the work procedure.

(3) Run the compute-bound stuff in a separate process from the screen stuff.
    Advantage:  the OS scheduler handles interleaving X event processing and
    your processing for you.  You don't have to restructure the compute-bound
    part of your application.  Disadvantage:  you have to deal with some sort
    of interprocess communication to pass data back and forth between the two
    processes.

--PSW

1260.2A fourth possibilityREINIG::REINIGThis too shall changeFri Aug 11 1989 16:1014
    Paul left out one possibility.  Your compute bound code can dispatch x
    events every so often.  TPU does this.  We have a timer that goes off
    every so often which sets a bit which tells us to dispatch X events. 
    Anyplace that TPU can loop, it checks this bit, and calls a routine to
    dispatch X events if necessary.  
    
    It still needs some fine tuning but it does work.  One reason we chose
    this is that it required very little change to our existing code.  We
    already checked for control C's everywhere and that check was in a
    macro.  So, all we had to do was add the timer AST and change the
    macro.
    
                                August G. Reinig

1260.3LISP provides another way, too.AITG::WELLSUnmatched parenthesisFri Aug 11 1989 18:1711
    Another possibility, for internal folks, is to use LISP.  We have
    threads (similar to Ada tasks) that we use for the same kind of stuff.
    (But this doesn't help Sue -- she works in our group, but they're not
    using LISP for their project. :-( )
    
    If anyone out there is interested in trying this stuff out, send me
    mail.
    
    Richard
    

1260.4DWOVAX::YOUNGin the iron grip of bureaucracySun Aug 13 1989 12:245
    Re .1 & .3:
    
    I thought that the DECwindows (& Xwindows) routines were not
    AST-reentrant, let alone fully reentrant?

1260.5Re: .4:AIRPRT::GRIERmjg's holistic computing agencySun Aug 13 1989 13:025
   Xlib is re-entrant, the toolkit and such are not.


					-mjg

1260.6We don't use the toolkit at AST levelREINIG::REINIGThis too shall changeMon Aug 14 1989 12:048
    The only thing we do at AST level is set an internal flag and use some
    X routines.  As .4 said, X is re-entrant.  We don't dispatch events
    until we are back at normal processing level.  This is why ALL of our
    loops check our internal flag.  It's a lot of checking, but it was
    already there.
    
                        August G. Reinig