[fpc-devel] threads questions

[Marco van de Voort]

> Hi, I have some (dumb) questions regarding threads. I'm sure that this issues 
> have been discussed before but I couldn't find any information...
> 
> - The attr parameter of the pthreads_cond_init fc (and others) on linux is is 
> declared as a var parameter, not as a pointer, but it should be a pointer 
> because nil is a valid parameter value. On the other hand, the pthreads unit 
> compiled for SunOS and BSD do declare the attr parameter as a pointer, so fpc 
> code using pthreads on linux is not portable to other unixes (compare de 
> pthr*.inc files). Which version is considered right? (I would prefer the 
> pointers one, because it would save me declaring many useless variables).

In general these files expose a lot of OS dependant fields, so they'll never
be 100% portable. I guess however that the linux variant is showing its age
here. Probably best is to overload also for ptr.

> - The std unix error constants (for example EBUSY) are declared in errnoh.inc 
> that is only included by the unit libc

> But I believe to remember that the 
> unit libc is considered deprecated (only for Kylix compatibility and not to 
> be used by new projects) isn't it?

Yes, stronger even, it never was any other way for portable development.

> So, which is the preferred way of getting EBUSY et al. declared: (a) use
> libc anyway, (b) include errnoh.inc, (c) declare it the project code?

The exact symbols are not defined. The error codes are prefixed with esys
(e.g. esysebusy) to not conflict with legacy Kylix code in the same project,
and are in unit baseunix (via unixtype).

> - The pthreads unit does not declare pthread_t, It exists in unixtype but 
> unixtype redefines also some other types that are already defined in 
> pthreads, causing compilation errors if included in the "wrong" order. 
> Shouldn't pthreads define pthread_t?

Afaik this is either an known problem under linux for which a bugticket
exists. It might even be already resolved in 2.1.4.