pefv700@perv.pe.utexas.edu (03/21/91)
I hope this group is ok for this. (I couldn't find a comp.x.programming `a la comp.unix.programming.) I have a FORTRAN simulator that simulates a physical process that proceeds through time. The two pertinent graphics during a run are: 1) a property of the physical system vs. time (in other words, a single-valued function) and 2) a cross-section of the actual 3D system at a point in time (each point in the domain will either be of characteristic "A" or "B" and color will be used to distinguish them). During the simulation run, the user should be able to type a key and get a new graphic of either type 1 or 2 (as above). And of course redrawing should be done as necessary. My question is: should I have 2 processes, one that controls the simulator? If so, what is the best way to get data from the FORTRAN program? sockets? Or should I have just one process that just checks for keyboard and button events periodically? Surely this has been done already. All comments are appreciated. Chris
thp@westhawk.UUCP ("Timothy H Panton.") (03/24/91)
pefv700@perv.pe.utexas.edu wrote: > My question is: should I have 2 processes, one that controls the simulator? > If so, what is the best way to get data from the FORTRAN program? sockets? > Or should I have just one process that just checks for keyboard and button > events periodically? I've been contracting on a chemical plant simulator and we chose the first route with no real regrets. The origional frontend ran on a PC with GEM , so we already had a suitable command-line type interface on the UNIX backend. We added a couple of new "commands" to it to allow it to support our new X frontend and off we went. Up until a month ago I'd have said that there was only one problem - designing the comms protocol. However I recently improved the backend so that it could respond much faster to external events, and found to my horror that the machine (a Sparc) was spending about 25% of the time context switching. I spent last week de-tuning the response of the frontend-backend link so that requests are serviced within 1 sec, rather than within 10 millisec. The 10 millisec stuff was implemented to support some inter-machine I/O and I'd just assumed it would be nice to use it on the intra-machine link. Not so. On the communication front we arrange for both processes to expect to see the other on stdio, and we have a third process that creates the links, dups a bit forks them both and then waits around, this allows easy debugging and we also do a "recover" when the parent process sees that one of its children terminated abnormally and starts a replacement. Hope that helps a bit. Tim. +----------------------------------------------------------------------------+ |Tim Panton, Westhawk Ltd. "Do not meddle in the affairs of Wizards, for | |Phone: +44 928722574 they are subtle and quick to anger." | |Email: thp%westhawk.uucp@ukc.ac.uk The Lord of the Rings. | |Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK. | +----------------------------------------------------------------------------+