Interrupt Handling Routines

[josh]

We believe that there are at least versions of Python that offer a std. library interface (no guarantee of type safety for what goes inside there) to interrpts. Examination of that might be a starting place for other interpretd languages with a comparable relationship to C.

[josh]

Another place to look – can Qt Quick (which is designed for embedded interrupt handling among other tasks & has an interpreted script language) be reduced to a smaller subset that is all interrupt appropriate?

[josh]

If one could go back & re-do signal/interrupt handler interfaces in a post-thread world, I think these features would be good:

a) interrupts naturally go to the thread that generated them where that interpretation makes sense. Otherwise they go to the default listening thread which can be designated in a multiple thread context, or to another thread that is specified for a particular type of signal (so long as its living).

b) Some sorts of common handlers can be resident to kernel & symbolically selected (no extra user land handling) => more common choices

c) more control of setjmp/longjump including all the info relevant to C++ exception handling – use what you actually need. The cleanup part of C++ exception handling should be available for execution prior to jumps to an unrelated, saved location. Where only the resumption location matters, it shouldn’t be necessary to execute setjmp at the spot.

Benefits? The concept of the signal/interrupt is to allow as fast as possible reactions to potentially important asynchronous events, with user code saying what is especially important and how to react to that. The change set is designed to allow the sorts of dynamic specifications & reactions that modern code would like to specify. Allowing more expressiveness potentially allows for more responsiveness & less overhead.

[josh]

Some “usr” signal(s) should be able to pass at least an 8 byte arg value, if not more data.

[josh]

Britain's Cameron Norrie has been beaten by Novak Djokovic in Friday's Wimbledon semi-final https://t.co/7hqR2tYFyT

— LBC (@LBC) July 8, 2022

Different contributors that create performance gains with extra synergy from less context switching:

lightweight context interrupt handlers to route the data from input as soon as it’s ready

multi-routine return/exist via direct call of mechanisms comparable to C++ exception unwinding/stack walking (try block ability merges with setjmp ability + other features)

Both, if done safely, reduce some useless memory thrash/work.

[josh]

“lightweight context interrupt handlers to route the data from input as soon as it’s ready”

Q: For initial handling of input, say in a web browser receiving network data streams, or a web server receiving multiple client requests – what sort of optimization is possible within a setof input ready interrupt handlers? What tasks, started sooner, lead to overall earlier completion of something noticeable in the system?

Which code, if any, takes significant advantage?

[josh]

setjmp/longjmp is a primtive design which C++ didn’t fix, while introducing a more advanced synchronous design, exception handling, that doesn’t provide a way to work with setjmp/longjmp or with asynchronous signal handling.

My thoughts about near field fix design:

say tryEpoch(nameEpoch) { …. } has the properties of try but also allows nameEpoch to be an argument to stack unwinding up to that point and it’s catch routines without going to the next point of execution after tryEpoch.

say stack=initStack(ThreadArgumentWorkFun,procFun1,procFun2,…procFunN) will default to main() in std programs & succeed if from main() default or an instance of pthread_create() or similar for more portability there is a unique stack sequence described by the name functions. In that case, it gives something which can be used like setjmp(). Otherwise it fails.

Thoughts?

[Author]

Posts