Interrupts

[Francois-Rene Rideau]

>>   In Tunes, the interrupted task would be basically be told
>>"now do your best to yield execution ASAP,
>>after putting the system in a rightful state".
>>The task would exit the current loop/iteration,
>>restore invariants needed for concurrent GC/whatever to take place,
>>then call the scheduler for next task.
>
> But what if it doesn't? Do you mean the proof system have ruled out such a
> situation already,
Exactly.
The Tunes compiler is required to produce code that fully cooperates
with whatever conventions have been defined
for the particular target environment/context.

Note that the topic has been discussed at length
on the Tunes (or was it tunes-lll?) mailing-list.
Well, you'll be able to see as soon as the mailing list archives
are up and running again.
Meanwhile, you could get the .tar.bz archives from
	http://www.eleves.ens.fr:8080/home/rideau/Tunes/files/list/
[get BZip 0.21 to decompress].

> perhaps by having a prerequisite saying that for example
> the objects/processes handling the network, floppy (input, but also output)
> or .MOD player must always get control quickly enough not to allow lack of
> preemption to slow them down?
Oh, there will be real-time constraints on cooperative scheduling,
but these might not be sufficient for real-time response to interrupt.
Now, interrupts that require real-time response will be treated in
Tunes just like they are in any OS: a handler will fill/empty the
buffers (with errors on underflow/overflow), and there you are!
Because Tunes wants to do better than traditional designs where
traditional designs fail doesn't mean that Tunes should not do the
same as traditional designs where these are successful!
Interrupting devices under Tunes will not be less serviced
than under Linux, DOS or Win*!

> Maybe that could be made (or automatically becomes?) an implementetion
> issue that you (the user/programmer) don't have to care about as long as
> you stick to HLL (as opposed to LLL).
Sure! This cooperative scheduler is how I intend to implement things.
Exact implementation techniques should surely not be part of
the standard HLL specifications! After all, if someone someday
finds a better way to do things, noone should forbid him to use it,
and if noone finds anything, then there's no need to forbid it.

>>Yes yes yes. Object code should be irreversibly produced for a particular
>>target, while a *high-level* language or maximal possible expressivity
>>should be used to represent user-level and/or portable objects.
> 
> What about people (companies) who wants to keep their source code secret?
> Should they be shot? :-) Are they not GNU-ish enough? As long as every
> object is small enough and has enough information/documentation about it's
> behaviour (a proof maybe?), it can always be rewritten by people who would
> like to modify it, so the problem is one of making the docs fine-grained
> enough. Maybe not something Macrosoft would agree to do...
>
About companies that want to keep their source code secret,
I'll forward to the list a message I wrote recently to Mr. Hamdani...

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"