[gambit-list] Marc, (not interrupts-enabled) ramifications and safe practices? Also (not safe)

Adam adam.mlmb at gmail.com
Wed Nov 7 21:14:43 EST 2018


Hi Marc!

Can you please explain the ramifications of (declare (not
interrupts-enabled))?

The effect of (not interrupts-enabled) that I have been aware of, is that
it disables thread switches in the green thread scheduling.

With respect to green thread switching, the same effect as removing the
interrupt sugar, can be achieved by setting the current green thread's
quantum to infinity.

This can be done by (thread-quantum-set! (current-thread) +inf.0) or even
better (##enable-interrupts), and is discussed at
http://gambitscheme.org/wiki/index.php/Using_Gambit_with_External_Libraries#Ensuring_singlethreaded_behaviour
and also further below in this email.

An example of when you want to disable green thread switches, would be when
you have Scheme code that calls C that then calls Scheme, meaning you have
a C stack frame in the stack - Gambit requires the user to rewind C stack
frames in exact reverse order or the program will get into an undefined
state right, and so creating a clean-room environment for guaranteeing that
by disabling thread switching, makes all sense in the world.


Reading the
https://github.com/gambit/gambit/commit/674ddff913cdfb7b3e73c6f78f3f034521982dc3
commit, where you fixed a stack overflow bug by changing a

(define (p) (declare (not interrupts-enabled)) ... (let () ... result))


to

(define (p) (declare (not interrupts-enabled)) ... (let () ... (let ()
(declare (interrupts-enabled) result)))


, I'm realizing that there may be more ramifications to (not
interrupts-enabled) namely that as a performance measure Gambit has
delegated some Scheme stack frame (aka msection) management logics to the
interrupt handler.

Is this so?

If so, what are safe coding practices relating to (not interrupts-enabled)?

Can a user ever have a reason to use it?

Is it actually a dangerous option that shouldn't be used by normal users??

The question "how much memory is available in an msection so that I can
write code that won't overflow it" is mostly irrelevant as the user *not* can
manage msection location anyhow e.g. there's no
##flush-msection-give-me-a-new-fresh-one! , right?

Can you direct me to where in the code the interrupt code sugar is located
(e.g. in standard library or in the compiler code)?

Brad mentioned that none of the code in _num that has (not
interrupts-enabled) "not does any allocations whatsoever".


Apart from the interrupts-enabled declare, two procedures are available
called (##disable-interrupts) and (##enable-interrupts) /
___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)().

While their names overlap with the declare, these are actually functionally
separate altogether from the declare, and have the effect of
(thread-quantum-set! (current-thread) +inf.0) and resetting the green
thread quantum back to its previous value, right?


Meanwhile, (not safe) only has the effect of skipping production of type
checks on variable accesses and it has no other effects than that, right?

Thanks,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20181108/a2873e31/attachment.htm>


More information about the Gambit-list mailing list