On Tue, Aug 7, 2012 at 2:05 AM, Emmanuel Dreyfus
<address@hidden> 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
address@hidden
_______________________________________________
Gluster-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gluster-devel