Pierre Abbat wrote:
> I suggest a couple of named pipes for control (the front end writes to one and
> reads from the other, and mprime vice versa). Since writing to a pipe whose
> reader is stuck can get you blocked when the pipe is full, and writing to a
> pipe with nothing at the other end results in a SIGPIPE, mprime should not
> output anything to the pipe unless told to do so, and should trap SIGPIPE and
> turn off output.
The current .ini structure is, I feel, sufficient for controlling the
operation of
the client, and preferrable. However, some signal should exist to force
the client
to re-read these settings after change; at least in *nixes this should
be easy
(Just handle HUP). As for data out of the client, I like to think that
the
existing save-state files would be enough, or could be made to be
enough. I'm not
sure how much cycles generating them frequently will burn, though, which
could be
a problem. Also the timing data is not easily accessible this way, but I
like the
approach used in the recently posted *nix GUI. And I concur with the
ideas that
the "extended GUI" should, if possible, be separate from the main client
so as not
to run a risk of messing up the results.
-Donwulff
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
