Hi Eric
Congratulations, the socket code compiles and works on SGI's! A few
observations from a quick trial run.
I put a monitor using fifos and one using sockets side by side and
rendered the elevation.dem raster map from spearfish in both. After
rendering several times the sockets seemed to behave slightly faster
overall. However, there were times when the fifos were faster. Several
things need to be taken into account though, like shared resources,
network activity (I was logged in remotely), etc. But the sockets were
faster more often.
The close on click feature works fine, and there is no backing store
problem either.
The only problems I saw (2 of them) concern interaction with tcltkgrass.
They are probably related since they deal with stopping the monitors. If
you choose to stop a monitor in tcltkgrass, or choose the "stop all x
monitors" option when you quit, it seems that Grass kills the monitors
(after stopping x0 I can start x0 again), but the actual windows remain
on the screen. Starting another x0 opens a new window, giving two
windows labeled x0. Of course, only one of them accepts graphics
commands. Note that this effect does not happen if I use the d.mon
command from the Grass shell, only with tcltkgrass. I'm not sure what's
happening with that one.
Anyway, thanks again for the great work. I think we should make sockets
the default process communication mechanism since it eliminates the
createfifos.sh script.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
