> I am designing an application in which I want to display graphics
> continously during execution. I figured that threads would be a good
> way of doing this but since we've got X11R5 here (for some reason)
> it doesn't seem to work. As soon as the thread makes an Xlib call, I
> get an x error and the program is terminated. ...
Xlib is not multi-threaded in R5. This is an X limitation, not an
XForms limitation.
I believe there is some support in R6 for multi-threading but I've not
had a chance to try anything to see how robust that support might be.
> ... I'm only planning on using one thread and therefore,
> the eventloop's behavior is the only thing I don't know how to
> control. If this doesn't work, is there any other way of
> accomplishing the same thing?
This is a topic that is discussed on this list quite frequently.
There are several approaches which you can take.
My particular favorite, since it is most conformant with the XForms/X
model, is to use an idle procedure (called a WorkProcedure in Xt
parlance) registered by fl_set_idle_callback(). This is a procedure
which is called by XForms whenever it has no events to process. The
idea is to break up your computing task into small chunks, say a few
iterations of an inner loop, and execute them in a background mode.
The nice thing about this model is that although it sometimes requires
a little redesign of the algorithm to make it fit you can make all the
Xlib or XForms function calls you want within the idle procedure with
no adverse consequences.
If you need to do something on a timed basis, check fl_add_timeout().
Another approach is retain your original algorithm design and to stick
an fl_check_forms() function call in the computational loop. This
will allow you to make XForms calls and do interaction while still
doing your computation. I've never favored this particular approach
since it strikes me as somewhat inelegant and counter to the event
driven philosophy of XForms but that's really just a matter of
personal taste. I know of several XForms users who have used this
approach and are quite happy with the results.
Finally, you can multithread through whatever mechanism provided by
your operating system. However, only one thread should make XForms
calls and the other thread should simply do their own computational
thing, communicating to the XForms thread by pipes, sockets, signals,
message queues, shared memory, or semaphores. This approach is
probably the most complicated to implement since it requires
synchronizing two or more processes and may necessitate elaborate
locking or mutual exclusion mechanisms to preserve data integrity.
There are functions in XForms to support signal and asynchronous I/O
handling. Refer to the manual for details. For a good exposition on
pipes, sockets, etc., check one of Richard Stevens's books, _UNIX
Network Programming_ or _Advanced Programming in the UNIX
Environment_.
Of course, there's no prohibition from any child process or cohort
thread from firing up XForms on its own to display and manage windows,
just as long as it does its own initialization of the XForms
interface.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/xforms-archive/