Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!rice!sun-spots-request
From: adimail!george@uunet.uu.net (George Pearson)
Newsgroups: comp.sys.sun
Subject: Sharing the entire data segment between tasks
Keywords: Miscellaneous
Message-ID: <1990Oct7.225628.1295@rice.edu>
Date: 7 Oct 90 21:30:00 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 42
Approved: Sun-Spots@rice.edu
Originator: spots@walhalla.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 335, message 4

Problem:

We have written a Sunview based graphics program that, upon user request,
needs to perform some extensive computing (taking several minutes).  Upon
completion, the user can view the results on the screen.  During the
computation, the user cannot perform any of the other graphics functions:
the process is "busy".  We would like to rectify this situation.  This
sounds simple so far but the graphics and computation are both based on
data structures containing as much as 10 MB of data.  We therefore don't
want to send data back and forth to a separate process and we'd rather not
reread the data and reconstruct the structures.  Instead we've come up
with the 2 alternatives below:

Possible solutions (with difficulties)

1.  Fork the process.  The parent continues the graphics service and the
child does the computation.  No exec is done so that the child can read
the parent's data and use it in the computation.  This is perfect except
that because of "copy-on-write", the child cannot modify even a single
variable without creating duplicate pages of data.  Results cannot simply
be placed into the data because the parent process will never see them.
The problem here seems to be how to get the entire data area to be
MAP_SHARED across the fork.

2.  Use a Sun lightweight process.  The data areas are then implicitly
shared. However an experiment showed that with the original process
running window_main_loop(), the compute process never starts.  Linking
additionally with the non-blocking i/o library causes the program to blow
off with window errors while it's just starting up.  In addition to these
problems, we'd need a pre-emptive scheduler that would allow the graphics
lightweight process to regain control whenever there was user input.

Notes on the solutions:

Number 1 seems to have the most potential.  The mmap function has the
ability to set "memory objects" to MAP_SHARED but requires an address,
length, fd, etc. and it's not clear where to obtain these.  (Alternatives
for getting data address and length appear to be: - the end, etext, and
edata functions - the proc structure at the beginning of the executable
file - using kvm_nextproc() Don't know if this is even on the right track.

Does anyone have any suggestions?