The idea to share the stack switching code between different projects is not new, see issue #10. Last year Kristján Valur Jónsson made another attempt: pull request #230:

The Stackman project (http://github.com/kristjanvalur/stackman) aims to provide simple
stack switching code for modern platforms. The aim is to have application-agnostic code that
performs the basic functionality of saving machine registers and switching stack pointer, leaving the custom code of saving/restoring stack and choosing stack pointer to a user callback.

The resulting switching code is very succinct and easy to verify.

I open this issue to discuss those aspects, that are unrelated to a particular implementation.

What

Make it possible to use Stackman to implement stack-switching instead of the current Stackless code.

Why - Benefits and Drawbacks

Are there any arguments, why the performance of Stackman is better/worse than legacy Stackless stack switching?

When

Now. Stackless 3.7 is near its eol and Stackless 3.8 hasn't been released. Stackman seems to be sufficiently mature.

How

Pull request #230 proves that Stackman can be used, but there are many more ways to do it.

Options

1. Install Stackman as an external project. Add a make install option to Stackman. In Stackless add an option --with-stackman to configure.
2. Like option 1, but automatically detect Stackman and use an option to disable Stackman (--without-stackman).
3. Add Stackman as a git submodule to Stackless. That's what pull request implement switching using the Stackman submodule #230 does.
4. Add a full copy of Stackman source (archive) to a sub-directory in the Stackless source code.
5. Add a partial copy of Stackman to the Stackless source code and automatically use it.

There might be more options.

Requirements

Some requirements. There might be more.

1. Using Stackman is a compile time option. It is still possible to use the legacy Stackless hard switching code.
2. No user visible changes in API, stability, usage, if Stackless uses Stackman.
3. Do not break a working build process, if building from a Stackless source archive. E.g.
   ./configure && make && make test && make install still works. Especially important for the Windows build process.
   As a consequence, Stackless should adhere to the Include-directory layout from C-Python.
4. If Stackman is not bundled with Stackless source (options 1 and 2), there should be a mechanism to detect, if the found/specified version of Stackman is compatible with Stackless.
5. No legal risk. Stackless currently is a leisure time project. (Currently I don't expect any problems here, it is just for completeness.)

Discussion

Just some preliminary thoughts

We can divide the possible options into two goups:

• option 1,2: Stackman is only available, if separately installed
• option 3...5: Stackman is always available

Currently Stackless is mostly used on Windows amd64 and Linux amd64 (32bit versions are fading away). On these platforms the existing hard switching code and building Stackless just works. Unless Stackman improves the performance, using Stackman or legacy Stackless stack-switching makes no difference. If there was a performance gain, we would prefer option 3...5.

Advantages of option 1 and 2:

• Implementation of option 1 or 2 is probably simpler than option 3 or 4. Adding a complete copy of the Stackman source causes its header files to live outside of ./Include. Therefore we would need to modify the installation process (make install and Windows Tools/msi) or the build process.
• Selecting the right library is a concern of the Stackman installation.
• Stackless source does not contain any precompiled binary.

Option 5 would be fairly similar to the legacy solution. Upgrading to a newer Stackman version become complicated.