Conference bulova::decw_jan-89_to_nov-90

    Look at the Intrinsics routines XtAddWorkProc and XtRemoveWorkProc.
    Work procedures are a push-down stack of routines to be called 
    when the toolkit mainloop has no events to process.  They should be
    of short duration otherwise the interface will appear to "freeze".
    The one on the top of the stack will keep getting called (when
    there are no events to process) until it "removes" itself.
    
    Leo

    Ah, opposite of what I thought.  I saw the routines, but if you
    read the documentation it never really tells you what they do.
    
    So if I have a lot of cpu bound computations my choices are:
    
    1. do it in one routine and sprinkle in some Xtprocessevent calls
    
    2. do it in a work procedure that does a litte bit of work, saves
    its state and can continue each time its called.   I assume it has
    to know how to continue where it left off.
    
    Thanks for your quick answer.
    
    Ken B.
    

    
    You are correct...
    
>    2. do it in a work procedure that does a litte bit of work, saves
>    its state and can continue each time its called.   I assume it has
>    to know how to continue where it left off.
    
    I would try to do it this way if possible, because it keeps you out
    of processing events and is therefore a bit "cleaner"...
    One of the parameters to XtAddWorkProc is a "client-data" field.
    One technique you can use is to make this a pointer to your
    "state" data structure to let your work procedure know where to
    continue...
    
    Leo

    re .3
    
    Thanks again.  Now all I have to do is go back and re-code...
    
    Ken B. 

    just a little added info/warning from someone who has used a work
    procedure...the work procedure is a function, not a procedure (ie
    it returns a value); the return value indicating whether or not
    the work procedure should be removed.  make sure you return the
    right thing.
    					-- dd

    Ah, so work procedures do not remove themselves when done.  They
    tell the calling program to remove them.  Is this correct?
    
    Ken  B.
    

    It's removed either by returning True from the function or by
    explicitly calling XtRmoveWorkProc.
    
    Ron

I'am confused about work procedures (but then I'am confused about a lot of
things)

Before I go any further is this right??

You add work procedures using  AddProcedure & remove using RemoveProcedure
... this just gives you a subroutine that gets called when ever
nothing else is happening  (IE button pushes , slider motion etc)
the work subroutine get passed a flag.. you use this flag to 
figure out where you are in the work code.. IE you break your
work routine code into a whole bunch of discreet lumps (of less than
0.25 sec) and use the flag to tell you which lump you must execute this time

Is this right???


If so.. what happens when you have code that cannot be broken into
discreet lumps?? IE a call down to a lengthy subroutine or opening
a network link to a (distant) remote node? Will this not 'break' your
work procedure.. IE you will stall the main line code (and hang button pushes etc)

	You are correct in your understanding of how work procedures are
invoked (you add them to the list of work procedures or remove them etc...).

	The part about the flags sounds a bit confused.  My understanding from
using work procedures is as follows:

	You have a subroutine that does something (something short).
	You add it to the work procedure list.
	It gets invoked.
	The ROUTINE returns either TRUE or FALSE upon completion.  This
	  tells the toolkit whether or not to reinvoke the routine later.

	I am not aware of any flag that X passes you.  You are allowed to pass
some client data, however.  You should be able to use that data to save the
state of the routine when you exit.

	I've used work procs to poll an attached serial device.  The routine
executes VERY quickly and returns TRUE so it gets rescheduled.  We've noticed
little or no degradation in the performance of the UI due to the work
procedure.  The application essentially runs entirely in the work procedure
except when there are UI events to handle.

	Check the doc on work procedures.  In the Ultrix doc set, the routines
are described in Volume 2 in the Programming subset, Appendix C.  Also in
Volume 6, Reference Pages, page 3-273.  Don't know where in the VMS doc set.

	If you'd like an example of a program using work procedures, copy
wonk::dxfsd.c and fsd.uil.  Feel free to send mail if you have questions.

Hope this helps.

RE: .9

>	I've used work procs to poll an attached serial device.  The routine
>executes VERY quickly and returns TRUE so it gets rescheduled.  We've noticed
>little or no degradation in the performance of the UI due to the work
>procedure.  The application essentially runs entirely in the work procedure
>except when there are UI events to handle.

I hope you only run this application on stand-alone workstations.  Your
application is busy-waiting (i.e., in a compute loop).  This could have
disasterous effects on other applications and on other users, if you're
running the application in a time-sharing environment.

--PSW

	Actually, I've run the application in both environments with little
trouble.  The work procedure spends most of its time waiting for a read to
complete (which shouldn't block out any other system activity and doesn't seem
to in tests we've run).  Once the read completes, a very quick calculation is
done and some pointer magic happens.  This loop executes twice per invokation
of the work procedure which then passes control back to the toolkit and askes
to be rescheduled.

	There simply isn't a whole lot of computing going on in the routine. 
The one problem I have encountered (this would be solved using timed reads) is
that if the device goes away and the read hangs, the application is history. 
Again, though, this does not effect other processes.