<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Marc!<div><br></div><div>Can you please explain the ramifications of (declare (not interrupts-enabled))?</div><div><br></div><div>The effect of (not interrupts-enabled) that I have been aware of, is that it disables thread switches in the green thread scheduling.</div><div><br></div><div>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.</div><div><br></div><div>This can be done by (thread-quantum-set! (current-thread) +inf.0) or even better (##enable-interrupts), and is discussed at <a href="http://gambitscheme.org/wiki/index.php/Using_Gambit_with_External_Libraries#Ensuring_singlethreaded_behaviour">http://gambitscheme.org/wiki/index.php/Using_Gambit_with_External_Libraries#Ensuring_singlethreaded_behaviour</a> and also further below in this email.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Reading the <a href="https://github.com/gambit/gambit/commit/674ddff913cdfb7b3e73c6f78f3f034521982dc3">https://github.com/gambit/gambit/commit/674ddff913cdfb7b3e73c6f78f3f034521982dc3</a> commit, where you fixed a stack overflow bug by changing a</div><div><br></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(define (p) (declare (not interrupts-enabled)) ... (let () ... result))</div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>to</div><div><br></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(define (p) (declare (not interrupts-enabled)) ... (let () ... (let () (declare (interrupts-enabled) result)))</div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>, 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.</div><div><br></div><div>Is this so?</div><div><br></div><div>If so, what are safe coding practices relating to (not interrupts-enabled)?</div><div><br></div><div>Can a user ever have a reason to use it?</div><div><br></div><div><div>Is it actually a dangerous option that shouldn't be used by normal users??</div><br class="gmail-Apple-interchange-newline"></div><div>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 <u>not</u> can manage msection location anyhow e.g. there's no ##flush-msection-give-me-a-new-fresh-one! , right?</div><div><br></div><div>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)?</div><div><br></div><div>Brad mentioned that none of the code in _num that has (not interrupts-enabled) "not does any allocations whatsoever".</div><div><br></div><div><br></div><div>Apart from the interrupts-enabled declare, two procedures are available called (##disable-interrupts) and (##enable-interrupts) / ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)().</div><div><br></div><div>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?</div><div><br></div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Adam</div></div></div></div></div></div></div>