Number: 492

Date:  4-Apr-84 11':17':28

Submitter: Sannella.PA

Source: JONL.PA

Subject: Errors in non-exec processes should always break

Lisp Version: 

Description: '
Date':  3 APR 84 15':15 PST'
From': JONL.PA'
Subject': Need an AR on the default handling of errors propogating to top-level in processes'
To':   LispSupport'
cc':   vanMelle, Bobrow, Tong'
'
Danny has often been "befuddled" by some computation which was started underneath the MOUSE process (started from an INSPECTor?), but which subsequently dies from an error.  Not being able to distinguish between a process which successfully completes and one which commits an error and is thereby killed (by the default for the RESTARTABLE prop), he has taken to setting NLSETQGAG to NIL.'
'
The system really won''t run properly, in many places, with NLSETQGAG = NIL, for a common strategy is to do (CAR (NLSETQ (WIN-OR-RETURN-NIL))).'
'
Possibly a change to the default processprop RESTARTABLE so that a'
BREAK is run; of course, a prop of NIL would still mean "kill", and YES would still mean "restart".'
'
-----'
'
Date': 28 Apr 84 17':12 PST'
From': vanMelle.pa'
Subject': Re': AR 492': Errors in non-exec processes'
To': JonL, Bobrow, Tong'
cc': vanMelle.pa, LispSupport'
'
There is clearly some confusion here.  If an NLSETQ suppressed an error, it also caught it, which means that the error DIDN''T propagate to the top level.  Therefore, running with NLSETQGAG=NIL shouldn''t help you.'
'
There is a different problem, one I see only rarely, that errors in a non-exec process kill the process rather than cause a break, due to the break package''s heuristics about when to break and when not to.'
'
Anyway, I''d like to see some examples of something that "does the wrong thing".'
'
-----'
'
Date': 28 Apr 84 21':07 PST'
From': JonL.pa'
Subject': Re': AR 492': Errors in non-exec processes'
In-reply-to': vanMelle.pa''s message of 28 Apr 84 17':12 PST'
To': vanMelle.pa'
cc': JonL.pa, Bobrow.pa, Tong.pa, LispSupport.pa'
'
Well, as I understood the problem from Danny, he initially spawned processes without an NLSETQ around the form, and that is when he discovered that if he were looking for the value returned, he couldn''t distinguish between a NIL returned normally, and an error.  So *then* he put NLSETQ''s in, along with setting NLSETQGAG to NIL.'
'
To me, this sounds exactly like what you called "a different problem" -- namely he didn''t get a BREAK in an error-generating process (possibly due to BREAK packages hokey heuristics?).'
'
Danny, any clarifications?'
'
  -- JonL --'
'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 30-Apr-84 12':29':55

Attn: vanMelle

Assigned To: 

In/By: 

Disposition: 

System: Operating System

Subsystem: Processes

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: 

Frequency: Everytime

Impact: Moderate

Priority: Hopefully

Status: Open

Problem Type: Design - Impl

Source Files: