Re: [evolution-patches] camel object bag assert failure backport

[Tor Lillqvist <tml novell com>]

Not Zed wrote:
> It also removes semaphores which are a problem with w32 porting i
> believe.

Thanks! 

Although, I am nowadays building e-d-s and evo using the pthread
implementation for Win32 from http://sourceware.org/pthreads-win32/ It
seems to work fine, so it isn't actually *that* important from the
Win32 porting perspective to get rid of pthread usage (including
semaphores) now.

Some of the pthread usage is currently nonportable though. pthread_t
should be treated as an opaque type. In the pthreads-win32
implementation it is a struct... (Also on HP-UX, I believe.) Thus one
cannot compare pthread_t values with the == operator, one must use
pthread_compare().

(I must say that I think it's a pity that the pthread implementation
on Linux doesn't encapsulate pthread_t in a struct, too. That would
force people to write more portable code...)

Those equality tests are trivial to change, of course. A bit harder is
the fact that there is no portable way to get a unique "identifier"
for a thread. (On Linux, where pthread_t is a scalar type (a long, I
think), the value as such can be used as an identifier, but this is
not portable.

This is mostly used in debugging output in e-d-s and evo, where the
code in CVS does things like printf("thread %lx: doing bla bla\n",
pthread_self()). This must be changed. One way is to have a function
that calculates a hash of the contents of a pthread_t, and use that in
the debugging output. Or maybe just output the pthread_t contents in
hex. It is after all possible that not all pthread_t values that refer
the same thread necessarily have exactly the same contents. Some of
the bits might be unspecified and random, some might indicate some
state of the thread.

Another thing is that there is no portable way to set a pthread_t to
"invalid". Code that uses some special token value to indicate an
uninitialized pthead_t (typically ~0) needs to be changed. Typical
usage in e-d-s is that a pthread_t is a field in a struct, so one can
use a separate boolean field to indicate whether the pthread_t field
is valid or not.

I'll submit a patch the with pthread_t portability changes later
today.

--tml