I have a few questions about this this branch that I'd like to see
answered prior to merging.
The enter/leave region functions seem... ungraceful, somehow. There is
a lot of repetitive code that could be papered over via a MACROLET,
the function names are ugly in context, and the /no-fixup bit could
just as easily be an optional or keyword parameter. But there's one
further possibility: Have you considered using an instruction-macro,
so that the call site becomes something on the order of (inst
enter-safe-region :no-fixup) ?
In the definition for +win32-tib-arbitrary-field-offset+, there is no
commentary as to what this offset corresponds to, it ends up just
being a magic number. Can this reasonably be added, along with a
justification for why hacking up an arbitrary field in the TIB is
"okay"? (I see that this is explained elsewhere, but there's nothing
to link the definition to the explanation... or vice versa.)
Why emulate pthreads and posix signal handling instead of doing
something more "windows-like"?
Why even have definitions for signals other than SIG_STOP_FOR_GC and
SIGPIPE (for interrupt-thread), and possibly SIGINT (for use by
Those are the major questions, to my mind, at least.
On Sun, Dec 26, 2010 at 2:48 PM, Kalyanov Dmitry
> I'd like to consider the possibility of merging Windows threads support
> into SBCL main tree. I've put up page with information about threads
> support at http://dmitryvk.github.com/sbcl-win32-threads/ (including
> links to the code).
> How should I proceed? Should I chop this patch to smaller pieces or can
> it be applied as one big patch? Safepoints may also be useful for
> threading on other platforms - should safepoints be ported first or it's
> better to refactored them later?
Smaller pieces? Definitely! Consider the linux/ppc threading changes:
Some 40 separate commits in the 1.0.41.x series (essentially, almost
all of the commits I made for that release were related to ppc
Integrating safepoints first? Yes, probably: It's plausibly useful on
other platforms (perhaps making it work on linux would be a good
start), and constitutes a "smaller piece", although it should probably
be split up into more than one commit as well.
> I'd like to hear any advice.
-- Alastair Bridgewater