[Gluster-devel] swapcontest usage in syncio.c

Anand Avati anand.avati at gmail.com
Tue Aug 7 09:31:09 UTC 2012

Was this behavior on a recent (last few days) version of git master HEAD?
There was a patch merged today review.gluster.com/3783 which might have an
influence related to what you are seeing.


On Tue, Aug 7, 2012 at 2:05 AM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Hi
> I am tracking portability problems in syncio.c. It maks heavy usage
> of swapcontext(), which is something not recommanded (it was removed
> from the 2008 edition of POSIX.1).
> As I understand, syntask_wrap() has the problem of retreiving the task.
> The parameter padded by makecontext() is not reliable, since the
> standard does not specify the type of the argument. Passing a pointer
> on an LP64 machine is doomed to fail if the par ameter is taken as
> an int by the implementation.
> Therefore the author of the code used thread specific storage to pass
> the task ,through synctask_set() / syntask_get(). I encounter
> crashes because syntask_get() in syntask_wrap() gets NULL, or even
> get a value different than the one synctask_set() gets as its argument.
> Using synctask_set() argument tend to be much more reliable at mine
> than trusting syntask_get().
> Logging pthread_self() and task in synctask_new(), syntask_switchto()
> and synctask_wrap, I can see the reason why it fails:
> syntask_switchto() / syntask_set() is sometimes done in a different
> thread that the one where synctask_wrap resumes. I suspect we fall
> into unspecified behavior with thread and swapcontext() interractions.
> Given that swapcontext() is not standard anymore, this would not be
> very suprising.
> I try to think about a workaround of the problem. An idea would
> be to store something specific to the context, like stack address,
> in struct synctask. syntask_wrap() could retreive the task by
> looking up its own stack address with getcontext() and search a
> matching task in a global list of tasks. I am not sure this is
> leading anywhere, though.
> --
> Emmanuel Dreyfus
> manu at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120807/b781b088/attachment-0003.html>

More information about the Gluster-devel mailing list