[<<][packetforth][>>][..]
Mon Nov 27 14:14:50 EST 2006

abort

need to re-think abort. basicly, it's a 'global' thing. there are 2
kinds of error handlers:

- task-local: saved on the return stack
- global: handled by the scheduler

before i can make tasks work, i need to figure out how to do local
error handling. the only place that has abort atm is
interpretation. the reason for this is simple: swapping/killing the
return stack during interpretation is problematic.

the real problem here is global resources. and this opens up a can of
worms: dynamicly bound variables should be task-local. the two biggest
problems are 'abort' and 'accept'. i need to have support for parsing
words in the interpreter.

changed 'accept' to 'read' which is a bit cleaner.

what about this: implement dynamic barriers properly using

* rewrite exceptions so they map RS -> (RS)
* add task switching words that respect this structure

this gets rid of the e-marker stuff.


so..

again...  why do i want this rewinding business? to make exceptions a
bit easier to handle. and cleaner to implement.

the thing is, it would be nice to know exactly how many data atoms are
consume when a try block is entered: there is no way to separate the
data stack like the return stack can be separated. that makes it hard
to use.. tough luck.

so, an exception handler consists of 3 nodes:

try:		 wrap return stack + save data stack size
		 register error handler

cleanup:	 OK -> clean up error handler + clean up
		 stack shielding

handle:		 restore wrapped stacks


the real problem i'm trying to solve is this:
- when an error occurs:
       * save current context -> backtrace
       * execute error handler


this is really the following: 
- a try block spawns a task
- when the task returns an error

maybe i should do the spawning first. this has an explicit 'n'
argument for the number of data atoms to detach.

: detach ( xt n -- task ) ;

if this mechanism is used for exceptions: spawning a task while
waiting for it's completion - backtrace is easily implemented: it's a
task's state.

i'm random walking again...  conclusion: winding a return stack
doesn't really help much implementation-wize. i think keeping things
as they are: abort and 'current' I/O are task bound, is ok for now.

so, let's do this one at a time:




[Reply][About]
[<<][packetforth][>>][..]