etxolpn@beppe15.ericsson.se (Ola Persson) (06/20/91)
I have some questions about the notifier.
1
How hard is the restriction "you should not use the following system calls"
, where the calls are for instance signal,system and so on? The manual uses the same expression (you should not) when talking about some signals to avoid , for instance SIGIO,SIGALRM and so on.
2
Can I always, even in the future use the notifier alone when running on a terminal ?
Thanks
Ola Perssonsarima@tdatirv.UUCP (Stanley Friesen) (06/25/91)
In article <etxolpn.677401967@beppe15> etxolpn@beppe15.ericsson.se (Ola Persson) writes: >1 >How hard is the restriction "you should not use the following system calls" >, where the calls are for instance signal,system and so on? The manual uses > the same expression (you should not) when talking about some signals to avoid, > for instance SIGIO,SIGALRM and so on. These restriction are quite important - especially the rule about not using the signals. Using any of the forbidden things yourself is a good way of totally crocking the notifier. (The signals listed are critical to the internal working of the notifier and it will not work at all if it cannot get them). Since the notifier library provides an alternate interface to all of the restricted functionality, avoiding it is not a problem. >2 > >Can I always, even in the future use the notifier alone when running on > a terminal ? As far as I know, yes. The notifier is actually an independent subsystem. It does not in any way depend upon X. (It is in fact absolutely identical to the notifier that came with Sunview). I have used the notifier by itself with no problem (to write a multi-threaded network server). I find it to be a great product in and of itself. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
fgreco@fis1026.govt.shearson.com (Frank Greco) (06/26/91)
> >How hard is the restriction "you should not use the following system calls" > >, where the calls are for instance signal,system and so on? The manual uses > > the same expression (you should not) when talking about some signals to avoid, > > for instance SIGIO,SIGALRM and so on. > > Since the notifier library provides an alternate interface to all of the > restricted functionality, avoiding it is not a problem. There is not a substitute for system(). System() does call signal() and wait() internally, so it should be replaced with a notifier version. There is a fork-type of pgm in the XVPM, but a lot of app pgmrs need the shell's help to run a pgm. Although I've found that good 'ole system() seems to work practically all the time, I understand the need to avoid the magical system calls with the notifier. So I started to write a version of system() that's a good notifier citizen (and uses whatever's in $SHELL instead of always using /bin/sh). I encountered a few stumbling blocks: 1. How do you simulate the blocking nature of system()? ie, if you don't bg the string, vanilla system() will tell the parent to wait under the child dies. You can't do this in a windowing environment; the app would be frozen until the child dies. I guess I could write an xvsystem() that passes, along with the string, a ptr to a wait fn. But how do I ignore all events everything until the child dies? (FRAME_BUSY doesn't ignore events...) 2. Is it possible (perhaps prudent...) to write a toolkit independent version of system()? Suppose a home grown library uses system() to rsh a pgm (it waits for the child). Now is it more appropriate to write a little library of routines like system(), signal(), etc... that is linked in if, say XView is used? Any suggestions anyone? Thanks again all, Frank G.
sarima@tdatirv.UUCP (Stanley Friesen) (06/28/91)
In article <jpbsipv@openlook.Unify.Com> fgreco@fis1026.govt.shearson.com (Frank Greco) writes: > There is not a substitute for system(). Oops, I missed that one. I guess I had never had the need to spawn a process anywhere except inside a TTYSW window. > There is a fork-type of pgm in the XVPM, but a lot of app pgmrs need > the shell's help to run a pgm. Hmm, as I think on it, there *must* be something in the library somewhere for this - after all a TTYSW does it! [Still, is using an undocumented interface kosher?] -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
fgreco@Unify.Com (06/29/91)
> In article <jpbsipv@openlook.Unify.Com> fgreco@fis1026.govt.shearson.com (Frank Greco) writes: > > There is not a substitute for system(). > > There is a fork-type of pgm in the XVPM, but a lot of app pgmrs need > > the shell's help to run a pgm. > > Hmm, as I think on it, there *must* be something in the library somewhere > for this - after all a TTYSW does it! [Still, is using an undocumented > interface kosher?] I wouldn't think a TTYSW does it. I would think that it just fork/exec's a shell and attaches the appropriate fd's to the pseudo tty of the TTYSW. Why would it want to call system()? Frank G.