Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!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: <6367@cbmvax.UUCP> Date: 21 Mar 89 20:38:56 GMT References: <0776.AA0776@julie> <6275@cbmvax.UUCP> <6299@cbmvax.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 115 Maybe we should start comp.sys.amiga.shells. :-) In article shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >Exactly what generates (and allocates?) the SIGBREAKF_CTRL_{C,D,E,F} >signals? CON:? console.device? dos.library? What? And how can you >change/disable/deallocate these signals? CON: assumes them, dos process startup always marks them as allocated. They are sent by CON:. >If a task is RemTask()'d while in a Forbidden state, does Exec perform >an implicit Permit(), or does the system merely die? (Same question >goes for Disable()/Enable()...) Yes, RemTask() implies Permit(). Also, any call to Wait() implies Permit() until your task wakes up again. >I take it the danger is using exceptions is that the task might be in >the middle of a ROM routine modifying system structures, and the >system may not be internally consistent when the exception takes >effect? (e.g. in the middle of an AllocMem() and modifying system >memory free lists...) If not, what? Yup. Also, the rom code maybe holding a lock on a semaphore, or using Forbid() locking on a system structure, etc. >Proposal - use exceptions to implement Amigix signal handlers. When a >system routine is called, call a sigdisable() function which sets a >flag in the Amigix process structure. If an exception is called and >the exception handler finds the flag set, it simply returns so as not >to interrupt any system calls. After the system call, sigenable() >would be called to enable the exception handler AND process any >pending signals. If you want to call ROM routines, I suspect that's the only safe way. >Both the signal disabling and resource tracking are best done at the >libcall level by patching all (ugh) of the library vectors... either >just in exec.library, or globally in all libraries. (Not too nice to >modify all the library jump vectors in the world, but I don't see any >other really viable alternative. NOT good. Better to implement your own libraries (gets you tracking as well) that call the system libraries. You don't want to break system stuff that calls the library entry points. >A patch could even be added to OpenLibrary() to patch any new >libraries installed into the system (such as disk-based libraries) if >they haven't been. Gawd, but what a mess. *sigh* Just have amigix.exec.library OpenLibrary create the libraries for you. >A common use is indeed ^Z followed by bg, for when the user forgot the >& sign, but real job control is need for you to actually switch >between jobs and multiplex them on one (virtual) terminal. Well, I do have ps and wait, which is sort of useful, but there are problems if multiple things want console input. >Unfortunately, it will most likely necessitate rewriting (in whole or >in part) the console.device... Possibly making a tty.device which >opens the console.device and adds functions, such as those needed to >do the full job control correctly. (e.g. Unix "stty TOSTOP", etc.) Actually it's not so much console.device as CON:. >Next question... exactly how do I go about handling both task traps >and Alert() calls (and "task held"'s?) such that I can recover from >them (killing [and cleaning up] the offending process and dumping core >if serious enough) without the usual GURU... (i.e. how can I cause >only a Signal() call when the system would normally GURU?) Task helds go through the task trap vectors, I think, and are set up by the DOS createproc code. You can catch any traps you want. Alert()s can be SetFunction()ed. >Next... How can I have the run-time library (opened by OpenLibrary() >in the process startup long before the new process image begins to >run) return a secondary value in the global variable errno? Is it >possible with allowing #pragmas for the library, or MUST I use stub >routines in a compile-time library? Is it possible to specify such an >return sequence with #pragma in Lattice? You'll have to tell the library in every call where errno is, I suspect (or at least the stub code). I don't think pragmas can handle multiple returns (nor can C generate them easily). >I suppose I could have as part of the necessary startup routine code >to store the address of errno in a field in the Amigix process >structure. That will work to. Or make errno a field in your process structure (can you say Result2?) >Next... WHY is there no ReallocMem() in exec.library??? Actually, you can't shrink because the number of small, seperate, bitmaps and other things needed by layers. I'm not sure layers could use ReAllocMem. Also, unix realloc has a really sick semantic: free(ptr); realloc(ptr,...) doesn't lose info under unix, and some unix programs (and programmers) use that. (YECH) >Next... How can a terminating task safely and legally deallocate the >memory section the terminiation code is executing it? Forbid(), >FreeMem(), RemTask(0L)? (with implicit Permit() at RemTask()?) Some >other way? What? It is safe to use memory that was FreeMem()ed under a Forbid(), IF you never call Wait() or any routine that might call Wait()! -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup