jeffd@norge.SGI.COM (Jeff Doughty) (01/04/89)
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