Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2007-05

threads questions

2 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mario R. Carro

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).

- 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? 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 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?

Thanks,
Mario

Reply by email

Marco van de Voort
to Mario R. Carro
Show quoted text 10 lines
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.

Show quoted text 6 lines
- 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.

Reply by email