[Gluster-devel] swapcontest usage in syncio.c

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


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.
>

Does that mean your implementation of *context() functions is implemented
as wrappers around pthreads? Can you verify that?

Avati


> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120807/cd5820e6/attachment-0003.html>


More information about the Gluster-devel mailing list