[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FreeBSD pthread_equal "bug"
- Subject: FreeBSD pthread_equal "bug"
- From: mtm at identd.net (Mike Makonnen)
- Date: Wed Jun 4 14:25:37 2003
On 04 Jun 2003 18:45:15 +0200
Kern Sibbald <kern_(_at_)_sibbald_(_dot_)_com> wrote:
> > Process id's can wrap around so it can eventually happen.
> Yes, true. However, on Solaris and Linux, it takes a long time,
> for the pthread_id to wrap around, and on FreeBSD it happens in
This is a very specious arguement since you are relying non-deterministic
behaviour in the other two implementations. They all "wrap around" eventually,
and a correctly implemented application will not rely on the length time before
> This bug does not highlight bad applications because most
> programmers will reasonably expect that pthread_equal() will
> not be the same for two different threads. It took me
> a long time to find this problem because I just could not
> imagine that pthread_equal() was not "working".
> This problem is extremely subtle and is likely to cause
> unsuspecting applications long months of bizarre
FreeBSD's libc_r behaviour is just as correct as the other two implementations.
You are relying on a non-portable feature of those implementations. In fact, I
am sure you will find this out when whatever Linux distro you are using
begins to use Red Hat's NPTL (Native Posix Threading Library), which does use
pointers as thread IDs. As I have already quoted to you in private mail:
>From IEEE Std 1003.1, 2003 Edition
The pthread_equal() function shall return a non-zero value if t1 and t2 are
equal; otherwise, zero shall be returned.
If either t1 or t2 are not valid thread IDs, the behavior is undefined.
The thread ID from the first thread is invalid since that thread no longer
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm_(_at_)_identd_(_dot_)_net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
mtm_(_at_)_FreeBSD_(_dot_)_Org| FreeBSD - The Power To Serve
Visit your host, monkey.org