Path: utzoo!utgpu!watmath!clyde!att!pacbell!hoptoad!gnu From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.windows.news Subject: Re: Fun with forkunix Message-ID: <5897@hoptoad.uucp> Date: 16 Nov 88 10:18:19 GMT References: Organization: Grasshopper Group in San Francisco Lines: 32 montnaro@sprite.steinmetz.ge.com (Skip Montanaro) wrote: > I've been trying to get around a bug in NeWS that makes starting programs > from user.ps unreliable. (It's bug #1004790. It's been around since NeWS 1.0 > and is still present in 1.1. I'll send the workaround to anyone interested.) > The symptom is that when starting programs from user.ps, such as: > > (psterm -ls -bg -li 16 -co 80 -sl 128 -C) forkunix > (emacs) forkunix > > sometimes the windows show up, but most times not. I believe this is because at the time user.ps runs, the server has not yet started accepting connections. The forked commands, e.g. psterm, race the news_server to see whether they'll attempt to connect to it before it creates the server socket. If the server wins the race, the window comes up; if not, the command dies and prints a message to /dev/null (where forkunix sends stdio -- boo). The easiest fix might be for user.ps to fork a lightweight PostScript process that periodically attempts to connect to the server (itself!), and only then runs the set of forkunixes, e.g: /waittilserving { .... } def { waittilserving (psterm) forkunix (emacs) forkunix } fork pop -- John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com "The network *is* the confuser."