Path: utzoo!mnetor!uunet!munnari!moncskermit!moncsbruce!conybear
From: conybear@moncsbruce.oz (Roland Conybeare)
Newsgroups: comp.sys.mac
Subject: stack sniffer evils
Message-ID: <363@moncsbruce.oz>
Date: 2 Feb 88 04:02:03 GMT
Organization: Comp Sci, Monash Uni, Australia
Lines: 54
Keywords: mac programming, lightweight processes, SysError()


	I have a problem, a solution, and a gripe.

The problem:
	I have written a multitasking kernel for the Mac.  It is intended
for use within an application rather than between applications, and 
features lightweight processes with fast context switch.
	A consequence of using such multitasking is that you often want
to allocate a process's stack space using memory from the heap.  However,
once your process actually runs with register A7 in the heap, the stack
sniffer picks this up and bombs your application.

The solution:
	The ideal solution to this inappropriate bomb would be for Apple
to have provided some way of turning off the stack sniffer.  The next best
thing would be to do it ourselves.
	Starting with this approach, I tried looking at the vertical
retrace queue, only to find that all the 'system functions' are done
by *one* queue entry - so removing it would disable the mouse, floppy etc.
	My current solution is to replace the SysError() trap with my
own version, which ignores 'stack in the heap' errors while passing other
errors on to the original trap handler.  This means the stack sniffer still
detects 'stack in the heap' up to 60 times a second, but my SysError() trap
says the application managed to recover from the error.
	I am unhappy with this solution for several reasons:
	o It's a hack.
	o The sniffer is still there, wasting clock cycles
	  (and thumbing its nose at me :-)
	o It's a hack.
	o I think it is a fragile solution.  It depends on the sniffer
	  not checking again for 1/60th of a second after my fake
	  SysError() returns, so my app. can get some work done.  In other
	  words, it's a hack!

The gripe:
	I think the event-based structure of the macintosh makes it hard
to program.  This is because different events may belong to different
execution contexts (for example a mousedown in an application window vs.
a DA menu selection), but we have to handle such events in a single
context, the main event loop.  This means we end up with lots of global
variables encoding the state of various 'natural execution contexts',
and our code is obscure to say the least.
	An excellent solution to this problem is to move to process-based
structure.  Each process has its own stack and PC which together encode
a 'natural execution context'.  When combined with some form of event
dispatching, we find our programming task is no harder than in a stream-
oriented environment.
	Thus my *GRIPE* is that the toolbox is trying to stop me programming
the way I want to!!! 

Roland Conybeare
(conybear@moncsbruce)

P.S. I would very much appreciate a response from Apple.