QDOS signal extension ===================== Introduction ------------ In UNIX and similar signals are used for (a) signaling and handling soft and hardware errors and exceptions like stack overflow, div by zero, bus and address exceptions (b) notifying processes about an situation needing urgent response, for example comunication with special devices (c) for comunication between processes (d) handling of certain keyboard or timer events like ctl-c(INT) or ctl-s, alarms, or events generated for example by the window manager (SIGWINCHD) (e) telling the process that it exhausted its limit on certain resources like memory, CPU time, number of open files In all of the above cases the normal execution of the process is interrupted at any point (even midinstruction in some cases) and the handler for the event is called instead. In QDOS (a) is already implemented through MT.TRAPV but unlike UNIX the handler routines are called in SV mode and need to take care about differing stackframes. It is my intention to provide an implementation of (b)(c)(d)(e) for QDOS through the signal extension. At the moment (c) is working fine at least on some machines. (d) is no problem either but you need some special way to generate this events - a job checking for a special keyrow combination or a button or hotkey appear more apropriate in QDOS enviroments than rewriting console drivers to send signals on ctl-d etc. For example the sleep button could send the job a signal to check whether it has its own sleep routine. sutil is a simple exmaple for this. (e) would work but QDOS does not use this possibility - it is therefore only usefull for non OS resources at the moment (b) (and partly also (e)) would require that it is possible to send signals from within device driver code or extern interrupt handlers, this not yet generally possible and it may require a special interface mechanism. Differences to UNIX signals --------------------------- What is described here is the low level interface, the c68 interface may hide most of these differences. sending and receiving signals works through channels but this is only a technical detail Receiving signals is controled by a set of priorities and various flags. There is no default handler. A job that does not explicitly establish a handler will simply ignore all signals. (err_nf beeing returned to the signaling job) Unlike unix, the signal numbers don't have any special meaning to QDOS - for example sending signal KILL or TERM doesn't kill the job, the number is simply passed to the signal handler routine which may or not kill the job. The only signal number that gets special handling in QDOS is 0 - it can be used to test whether a job exists and has established an signalhandler.(err_bj, err_nf) Neither QDOS nor this extension do check whether the signal number is a valid signal number There is only one (at a time) handler routine for a job serving all signals, it needs to do explicit dispatching. Installation ------------ lrespr signal_cde and if you wish easy signal sending ert hot_res(chr$(236),sutil) : rem alt-F2 Using signals ------------- if you don't intend to program this extension see sutil_txt and don't care about the rest of this document. Getting version of signal extension ----------------------------------- not very interesting, see sending signals. Signal handler -------------- qsignal_h : struct QDOS_SIGH structure that stores priority, flags, and address of the handler for a job receiving signals. This structure may extended in the future, this would be marked by some extra bits in priority, so it is very important to keep the priority in a well defined state. In assembler this is Offset.size 0.w $4afc * 2.l '%SIG' * magic 6.l sighnd * pointer to sighandler routine or 0 10.l stackbot * dont signal if a70 A0.L = chid A1.L = priority ; give it this priority. All reserved bits ; in priority should be cleared A2.L = usr_val ; may have special meaning for certain signalnumbers Returns: D0 error code D1.L ASCII version of extension if D0<>-1 D2,A0-A2 unchanged Errors: err.bj : bad job, signaling to BASIC or waiting for nonexistent job (the latest shouldn't happen really) err.om : job supposed to receive signal doesn't have enough stack err.nf : no signalhandler struct established for job err.bl : signalhandler found but has bad MAGIC id err.ni : failed due to some feature not yet implemented (REQSIGSTACK) err.ro : priority too small Returning without error means that the receiving job will start signal processing next time it will get CPU time (unless someone kills it or some of the defere flags apply). Thus it makes little sense to signal jobs with priority 0. signal nr 0 is never delivered to any job. Instead 'sending' it can be used to test whether the job exists and has established a valid signal handler (returns 0 or err.bj,err.nf,err.bl). At the moment it is not possible to send a signal to a job that is in SV mode (and for example suspended itself) Signals sent with the defere flags may never be processed by the receiving job. This is because they are simply stacked on the stack, thus some of the previously called handlers may choose to exit by longjmp() or exit() skiping them. Restrictions ------------ must not be used to interrupt jobs that store informations below the stack pointer, e.g move.l d1,-6(a7) I may implement sigstack allocation which would not have this restriction. Future options -------------- I will try to get the extension working on as many QDOS like systems as possible Let me know what you need. Author ------ Richard Zidlicky rdzidlic@cip.informatik.uni-erlangen.de Babenbergerring 69 (0)951-55175 96049 Bamberg Germany