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]
