Where are all the unix wizards ????

[Blair P. Houghton]

In article <18949 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
>In article <1753 at inews.intel.com> bhoughto at pima.intel.com (Blair P. Houghton) writes:
>>different languages on a system that has neither named
>>pipes nor a debugger capable of grokking the multiprocess
>>paradigm...
>
>Named pipes are an easy problem to overcome.  You write a
>device driver [...]

I have no authority to write a driver.  This here's an
application program in a third-party CAD environment, with
no way (no source license, neither) to alter the kernel's
functionality.  Doing so would require redoing
acceptance-testing of all the software we own or wrote for
these machines.  NFW.

I'm hacking around it by passing filenames as command-line
arguments and using the files as drop-boxes for commands
that the several processes can read and interpret.  There's
one program that does nothing but wait around to be hit with
a SIGINT so it can SIGCLD its parent.  It's sort of a
1/n-nplex communication system; or, named pipes with external
blocking.

Come to think of it, it's _five_ different languages.

>I don't know what to suggest as far as the debugger
>goes.  The most clever hack I've seen is piping to an
>ADB subprocess which started the program you want to
>debug.  Hmmm.

The system provides a debugger that can attach a running
process, so I may put hard waits into the code, then
start n versions of the debugger, each in the proper source-
directory for the executable to which it's attached.

				--Blair
				  "Which tie goes with
				   this color pointy hat?"