René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"hard switching using Stackman","articleBody":"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: \r\n\r\n\u003e The Stackman project (http://github.com/kristjanvalur/stackman) aims to provide simple\r\nstack switching code for modern platforms. The aim is to have application-agnostic code that\r\nperforms 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.\r\n\u003e \r\n\u003e The resulting switching code is very succinct and easy to verify.\r\n\r\nI open this issue to discuss those aspects, that are unrelated to a particular implementation.\r\n\r\n**What**\r\n\r\nMake it possible to use Stackman to implement stack-switching instead of the current Stackless code.\r\n\r\n**Why - Benefits and Drawbacks**\r\n\r\nargument \\ stakeholder | Stackless maintainer | Python developer | end user\r\n------------------------------ | ---------------------------- | ------------------------ | -----------\r\nStackman is simpler to maintain. | + |   |\r\nSupporting a new platform / architecture / compiler does not require changes to Stackless, only to Stackman |  | + |  |\r\nStackless own hard switching code works well, Stackman adds complexity to the overall project | - |  |  |\r\nPerformance is better / worse  |  |  | +/- | \r\n\r\n_Are there any arguments, why the performance of Stackman is better/worse than legacy Stackless stack switching?_\r\n\r\n**When**\r\n\r\nNow. Stackless 3.7 is near its eol and Stackless 3.8 hasn't been released. Stackman seems to be sufficiently mature.\r\n\r\n**How**\r\n\r\nPull request #230 proves that Stackman can be used, but there are many more ways to do it.\r\n\r\n_Options_\r\n\r\n1. Install Stackman as an external project. Add a `make install` option to Stackman. In Stackless add an option `--with-stackman` to configure. \r\n2. Like option 1, but automatically detect Stackman and use an option to disable Stackman (`--without-stackman`).\r\n3. Add Stackman as a git submodule to Stackless. That's what pull request #230 does.\r\n4. Add a full copy of Stackman source (archive) to a sub-directory in the Stackless source code.\r\n5. Add a partial copy of Stackman to the Stackless source code and automatically use it.\r\n\r\nThere might be more options.\r\n\r\n**Requirements**\r\n\r\nSome requirements. There might be more.\r\n\r\n1. Using Stackman is a compile time **option**. It is still possible to use the legacy Stackless hard switching code.\r\n2. No user visible changes in API, stability, usage, if Stackless uses Stackman.\r\n3. Do not break a working build process, if building from a Stackless source archive. E.g. \r\n   `./configure \u0026\u0026 make \u0026\u0026 make test \u0026\u0026 make install` still works. Especially important for the Windows build process.\r\n   As a consequence, Stackless should adhere to the Include-directory layout from C-Python. \r\n4. 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.\r\n5. No legal risk. Stackless currently is a leisure time project. (Currently I don't expect any problems here, it is just for completeness.)\r\n\r\n**Discussion**\r\n\r\n_Just some preliminary thoughts_\r\n\r\nWe can divide the possible options into two goups:\r\n\r\n* option 1,2: Stackman is only available, if separately installed\r\n* option 3...5: Stackman is always available\r\n\r\nCurrently 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.\r\n\r\nAdvantages of option 1 and 2:\r\n\r\n* 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.\r\n* Selecting the right library is a concern of the Stackman installation.\r\n* Stackless source does not contain any precompiled binary.\r\n\r\nOption 5 would be fairly similar to the legacy solution. Upgrading to a newer Stackman version become complicated.","author":{"url":"https://github.com/akruis","@type":"Person","name":"akruis"},"datePublished":"2021-06-24T21:25:14.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":13},"url":"https://github.com/278/stackless/issues/278"}