On Fri, Dec 03, 2004, Ralf S. Engelschall wrote: > On Fri, Dec 03, 2004, Stefan Brantschen wrote: > > > I can successfully create (pth_uctx_create), make (pth_uctx_make), and > > switch from/to (pth_uctx_switch) my contexts. > > > > However, saving (pth_uctx_save) and restoring (pth_uctx_restore) a > > context results in a segmentation fault (signal 10) on restore. Also > > switching to a saved context causes a crash, from which I infer that I > > don't manage to _save_ my context properly in the first place, as the > > switch works otherwise. > > > > Is there anything specific I should observe? I understand that through > > calling pth_uctx_save anywhere in my thread I can restore the state at > > save-time anytime later through pth_uctx_restore, so that the thread > > continues right at the position of the previous save? Do I miss > > something?! > > I think GNU Pth is using the MCSC machine context switching method > and there the boring getcontext(3) return semantics break GNU Pth's > pth_uctx_save(). I'm trying to find a workaround, but in the meantime > I guess you can workaround yourself by forcing GNU Pth to use a > different machine context switching method. For instance rebuild it with > --with-mctx-mth=sjlj and see what happens...
Shit happens: I've now fixed the internal pth_mctx_save() functions for the getcontext(3) situation but then had to discover (shame on me) that the pth_uctx_save() and pth_uctx_restore() API functions unfortunately were broken by design because they are C _functions_. They _cannot_ work at all! They are functions, hence this leads to one more deadly nesting on the run-time stack which effectively causes the pth_mctx_restore() in pth_uctx_restore() to return to the end of pth_uctx_save(), but then the control flow unfortunately returns to the pth_uctx_restore() caller instead of the pth_uctx_save() caller because the call to pth_uctx_restore() had already overwritten the run-time stack position where the original return address for the pth_uctx_save() call was stored. The only workaround would be to #define pth_uctx_save() and pth_uctx_restore() as C _macros_, but this then would require that lots of the GNU Pth internals from pth_mctx.c would have to be exported in the GNU Pth API (which in turn is not acceptable). So, the only consequence is to remove the two functions again from the GNU Pth API. On the other hand, it is no great problem, because the uctx sub-API was intended to let others implement user space threads theirself by levering the GNU Pth internals. And for implementing user space threads, one doesn't need save/restore functions. There it is fully sufficient to have make/switch functions (which are still available). So, sorry for the confusion with the pth_uctx_save/pth_uctx_restore functions. Just forget them immediately. They will be gone with GNU Pth 2.0.3. Thanks for prompting my investigation on this issue. Yours, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ GNU Portable Threads (Pth) http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List [EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]