friedl@vsi.UUCP (Stephen J. Friedl) (05/26/88)
OK guys.and.gals,
We have a curses-based message-center application (like a
"while you were out" pad for telephone operators). We would like
the operator to be able to put a caller (and his/her message) on
hold and take another call. We *could* rewrite our application
to do this manually, but we would like to do something
(hopefully) a little more clever.
We want to have a handful of these processes running at
once, talking to the terminal via Sys V SXTs. Our first version
uses a shl-like program to swap back and forth between two
applications on ^Z -- it sends SIGUSR1 to say "you're up,
redraw". This works but is kind of slow. There must be A
Better Way.
Generally speaking, we want curses to know about the other
sessions. If we put curscr in shared memory (again, speaking
generally), and can "somehow" link the various windows structures
together, with a little mutex around the shared access, it seems
that this could be extended generally to a pretty slick little
windowing system where child curses processes would be largely
unaware that they were running in a multi-process environment.
Has anybody done this? Are we out of our minds?
Related to this, are there any good refs on Sys V SXTs? We
have figured out quite a bit about them but questions remain.
Thanks,
Steve
--
Steve Friedl V-Systems, Inc. (714) 545-6442 3B2-kind-of-guy
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedldg@lakart.UUCP (David Goodenough) (05/31/88)
From article <687@vsi.UUCP>, by friedl@vsi.UUCP (Stephen J. Friedl): > Generally speaking, we want curses to know about the other > sessions. If we put curscr in shared memory (again, speaking > generally), and can "somehow" link the various windows structures > together, with a little mutex around the shared access, it seems > that this could be extended generally to a pretty slick little > windowing system where child curses processes would be largely > unaware that they were running in a multi-process environment. > Has anybody done this? Are we out of our minds? Basically, as I read it, you want several processes to be able to output to curses and have everything look sensible. Why not create a "curses server" which uses a socket / named pipe mechanism to receive curses requests, and then does them. That way you only have one "curses environment", but it fields all the requests. As to the exact nature of a request I'll leave that for you to decide (I am not going to do system design for a software package based on a single screen description :-) :-), but with a scheme such as this it should be possible. Comments (Flames :-) anyone? -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!adelie!cfisun!lakart!dg +-+-+ | +---+