Graphics from multiple threads

[Jeff Doughty]

Mike Muuss reported some problems with the 4D/20 and the 4D GTX.  I can
address the problem with multiple threads on the MP machine.

There is a limitation (imposed by software) that only the original parent can
access the graphics pipe.  The SGI demos available ARE multi-threaded, but
only a single process performs graphics.  Fixing this limitation is one of
our highest priorities for the next major release.  Currently, this release
is tagged as 4.0, and is scheduled for around October 1989.

For a brief description of what is happening:  The graphics pipe is mapped
into the user program's address space.  When the program fork()s for sproc()s,
this pipe is unmapped.  Thus when a child process attempts a graphics call
that accesses the pipe, it will dump core with a segmentation fault.  I noticed
that this behavior is not documented in either the fork(2) or sproc(2) man
pages -- I will remedy this.

The reason that the graphics pipe is unmapped across a fork/sproc is that
a great deal of software relies upon the fact that a pipe context corresponds
to a single process.  We felt that we could not change this in time for the
3.1 release.

As you read this, this limitation is being remedied.  Currently, we are planning
to introduce a new "share bit" to sproc (PR_SGRAPH) that indicates that the
threads would like to share graphics.  If this bit is on, the graphics
pipe context will be inherited across the sproc().  The user program will
be responsible for ensuring mutual exclusion of pipe accesses.


					Jeff Doughty
					UNIX group