Re: [Syllable-developer] Porting help

[Stefano D'A. <zan...@gm...>]

2008/10/26 Kristian Van Der Vliet <va...@li...>:
>> - the library you gave is name libpthread.so.2 while
>> /system/libraries/libpthread.so linked to
>> /system/libraries/libpthread.so.1 (using Syllable 0.6.5) - I guess
>> this implies that my stuff will only work with Syllable >= 0.6.6?
>
> Yes, but we do ship an ABI compatible libpthread.so.1 and I could &
> should apply the same fix there.

I don't really care, the only thing I care about is the "minimum
requirements" thing (so 0.6.6 should be it anyway)  ;-)

>> One of the two remaining problems goes like this:
>>
>> * the main thread allocates a mutex (ok)
>> * another thread locks it (ok)
>> * the same thread which locked it tries to unlock it, but
>> pthread_mutex_unlock() returns EPERM
>>
>> The mutex type is PTHREAD_MUTEX_ERRCHECK and it seems to always work
>> this way.
>
> Thanks, I'll look into it. Does it make any difference if the mutex is
> not MUTEX_ERRCHECK?

I tried without setting mutex type and it works correctly, but...
another problem came out: pthread_join() occasionally returning ESRCH.
Now, these tests work properly at least on Linux, so I'm pretty sure
that the code is valid.

In this case the test launches one hundred threads, lets them do some
concurrent insertion on a list, then waits for each one of them using
pthread_join(). pthread_join() is called inside a for loop which scans
the array of threads. The ESRCH return happens usually for the second
or third thread trying to be joined, so it does look like some kind of
bug.

Now, I understand these kind of stuff is quite hard to debug, so if
you want to reproduce these bugs on your own I can give you detailed
instructions on how to obtain and build the code I'm working on,
otherwise I can just keep up pinging you whenever I have problems. You
choose ;-)

>> The last problem is a fault of mine... however I noticed that dlsym()
>> sets errno to 131 when not finding some symbol (using strerror I get
>> "Unknown error - 131", but I see it is ENOSYM in errno.h), which is
>> probably fine since the POSIX standard doesn't seem to even mention
>> errno is the dlsym page... however, in case you are interested in
>> that, all other OSes I tried probably don't let dlsym set errno
>> (Windows/MSYS, Linux, BSDs), while the AIX man page for dlsym states:
>>
>> "If the named symbol is found, its address is returned. If the named
>> symbol is not found, NULL is returned and errno is set to 0."
>
> Hmm, that's what it should be doing, but libdl does use the native call
> get_symbol_address() which *may* set errno. libdl itself doesn't touch
> errno, so it wont clear errno to zero if get_symbol_address() fails.

As said, I think your way of doing things is perfectly valid and
POSIX-compatible, so I don't have problems with that. However some
buggy software could rely on this kind of behaviour, so it's up to you
whether you want to support those too. Just trying to help :-)

Stefano