[Python-Dev] Trial balloon: microthreads library in stdlib

["Martin v. Löwis"]

Richard Tew schrieb:
> If there is no Stackless 'hard switching' available (the stack
> switching done with assistance of assembler) for the platform it is
> being compiled on, then compilation proceeds without Stackless
> compiled into Python.  The module is not available.  The process
> of adding support for additional platforms is rather straightforward
> and with access to them I can do it if required.

I don't think portability to all systems should be necessary.
Rather, there should be a clear demarcation as to what works and
what not, and that demarcation should be fully understood so
that anybody using it could know what the restrictions are.

> I don't know about SEH but I believe support for SPARC was added
> in 2002.
> http://svn.python.org/view/stackless/trunk/Stackless/platf/switch_sparc_sun_gcc.h 

My concern here is more of the kind "what about the next processor?"
Is there some uniform way of dealing with it, if not, is there an
explicit list of architectures supported? Is there, or could there
be, an automated test telling whether the implementation will work?

> Right.  I imagine that if there are still problems like these, they
> will be brought to light when and if patches are submitted. But for
> now I will address what you mention just so that people don't
> assume they are still the case, especially since Stackless has
> been rewritten since then.

This also contributes to misunderstanding. When is "then"? I'm
talking about the "new" implementation, the one that bases on
setjmp and longjmp, and copies slices of the stack around. It
has been rewritten after that implementation strategy was
implemented?

> Perhaps my pursuit of better support for asynchronous calls
> has led to some confusion.  Stackless is an implementation
> with minimal changes to the core.  It does not include any modules
> which monkey patch.

That's good.

> It was considered and quickly dismissed to modify the socket and
> file support in the core at C level to do what was needed. Primarily
> because it would complicate the limited changes we make to the
> core.

This is also something to consider: "minimize changes to the core"
should not be a goal when contributing to the core (it certainly
is when you maintain a fork). Feel free to make any changes you like,
completely deviating from the current code base if necessary, as
long as
a) the resulting code still works in all cases where the old code
    did (if there are changes to the semantics, they need to be
    discussed), and
b) the resulting code is still as maintainable and readable (or
    better in these respects) as the old code.

This misconception is what kicked out the first attempt to merge
setuptools: this was apparently written in a way to minimize changes
to the core, and also to preserve semantics unmodified in all
details. By doing so, it became less maintainable than if it had
taken the liberty to change things.

Of course, then you have two versions to maintain: the in-core
version that nicely integrates, and the out-of-core version,
that has minimal changes. It first takes effort to create the
version to contribute, and then also the trick is how to keep
both of them maintainable, ideally from a single source.

Regards,
Martin