Re^2: the unsafe signals controversy (grainy)

I thought the next step was rather obvious. If there are certain opcodes that can take a long time to run, then the code run by those opcodes should be made smarter, releasing the critical section (or whatever else it might be called) during the parts of the opcode when blocking I/O is being done and unlocking it briefly and repeatedly at 'safe' points if the opcode involves some long-running actions such as looping.

- tye

Comment on Re^2: the unsafe signals controversy (grainy)

Replies are listed 'Best First'.
Re: Re^2: the unsafe signals controversy (grainy) by TimToady (Parson) on Mar 23, 2004 at 21:16 UTC
Yes, that's part of the solution. Another part is to detect duplicate signals and failover to the unsafe system if it is determined that the safe signal is not being delivered in a timely fashion. Then the poor schmuck bouncing on Ctrl-C has a chance to bomb out of his program sometime before next October.	[reply]
Re: Re^2: the unsafe signals controversy (grainy) by Old_Gray_Bear (Bishop) on Mar 23, 2004 at 18:46 UTC
Not unlike the move-long (MVCL) and compare-long (CLCL) instructions in the MVS Architecture (IBM OS/370, OS/390, z-OS, or whatever they are calling it today). The instructions operate on blocks of data up to 2^^24 bytes in length, but the micro-code stores state and take interupts every 1024 bytes. The Architecture also has save-state and resume-state functions implemented as single instructions, and hardware save-areas reserved for six different kinds of interupts, so it is easy to receive interupts in a timely fashion. IIRC, before the advent of the outboard I/O Subsystem, all of the I/O programming was done the same way -- start a transfer of 32 bytes, wait for it to finish, check status, transfer-in-channel back to the start of the I/O command chain; the TIC instruction was interupatable, the channel commands weren't. ---- I Go Back to Sleep, Now. OGB	[reply]