george@uunet.uu.net (George Pearson) (10/08/90)
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?
venkat@uunet.uu.net (D Venkatrangan) (11/01/90)
In article <1990Oct7.225628.1295@rice.edu> adimail!george@uunet.uu.net (George Pearson) writes: >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. Use shared memory. Also, use vfork() instead of fork() and follow it immediately with the exec of the child. Pass the shared memory ID from parent to child as a command line arg in the exec call. In the child, map the shared memory ID to a virtual memory address using the shmat() call. If parent has stored pointers to locations within the shared memory you should try to map it to the same virtual memory address as in the parent. D. Venkatrangan Matrix Computer Systems, Inc. 7 1/2 Harris Rd, Nashua, NH 03062 suneast!venkat uunet!matrix!venkat (603) 888-7790