Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: <6299@cbmvax.UUCP> Date: 15 Mar 89 23:36:59 GMT References: <0776.AA0776@julie> <6275@cbmvax.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 66 In article shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >In article <6275@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > >> What else? How about a standard tc_ExeceptionCode? > >> Make SIGBREAKF_CTRL_C, and ^E exceptions. ^C will > >>cause an "abort()" routine to be run. (signal() or sigvec()'able of course) > >>The standard abort() should be able to run some number of clean up > >>functions, and then it should call "exit()" > > > Can't be done unless you can GUARANTEE the PC will not be in a ROM > >routine, or with a Forbid() or LockIBase or ... held. Exceptions aren't as > >useful as you think. > >I haven't looked into exceptions too closely, but they seem to be of >some value, at least. How much, I'm not quite sure. They are of some value, but not as much as unix signal handlers. The idea originally was the same as Unix signal handlers, but it turns out to not be as useful, since they can cause important resources to be lost, and locking mechanisms to be defeated. > > One can get job control (at least the unix ^z part of it) > >without exceptions. The shell simply notices ^f and stops waiting for > >the current sub-process to complete. Does require running all > >programs in other processes. This has been done by at least one > >person. > >But that isn't really job control. It's more like ^Z followed by a >bg. It doesn't stop the job, only waiting for it. How about having a >function to suspend a task? It could freeze the exec task, optionally >causing an exception so the process can clean up some... True, it's not exactly the same semantics as ^Z, but it gives you the most commonly used feature of it. There is no real support in exec for non-executing tasks. > >> It ISN'T fork()/exec(), but it does make a much more orthogonal > >>system, shells send messages to "execute" servers, much the same > >>way that comm programs send messages to "serial" devices... > > In fact, exactly how I do it. >Meaning? Meaning in my shell (though maybe not in the ancient version you have) I send messages to subprocesses that do all actual program execution for me. The message includes seglist, priority, current directory, input and output streams, etc, etc. When the program exits it sends the message back with the return code. I can have any number of these running for pipes, or background tasks (via ^f or &). >As for implementation, I think the way to go is to number file >descriptors sequentially starting at 0, as in Unix, with 0 for stdin, >1 for stdout and 2 for stderr. However, the file descriptors would >NOT be kept in a static array, but instead in an Exec list, which >would be sorted from most-recently-used to least-recently-used -- when ... >That should be the most efficient while keeping everything dynamic and >flexible. Finding a free file descriptor for and open() or dup() call >would be quite inefficient, however. Unless, perhaps, a list of file >descriptor "holes" were kept... Only keeping track of unused >descriptors up until the highest-numbered file descriptor (which would >also be recorded) since all after that one are automatically free... It sounds pretty good to me. Just make sure close merges in the holes correctly (I assume the holes will stored as ranges). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup