[fpc-devel] CSuspendThread/CResumeThread

[Jonas Maebe]

On 8 nov 2006, at 10:42, Ales Katona wrote:

> Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with:
>
> rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp
> cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got
> "LongInt", expected "Pointer"

So either TThreadID or pthread_t is declared wrongly for FreeBSD  
(since that routine passes a TThreadID to a routine expecting a  
pthread_t)

> Note:
> unixtypes thread_t = pointer

No. unixtype includes ptypes.inc. ptypes.inc is OS-dependent. For  
*BSD and Darwin, pthread_t (not thread_t) is defined as a pointer.  
For Linux it's defined as a cuLong. It's not defined in that file at  
all for Solaris, which is a bug I think (it's defined in solaris/ 
pthread.inc instead).

> pthreads.inc thread_t (BSD and linux) = cInt {linux is Longint but
> that's just bug)

I don't see this. Afaics, pthread_t (and ppthread_t) is used  
appropriately everywhere in pthread.inc for both Linux and FreeBSD. I  
didn't check all declarations in detail, but at first sight the cInts  
(and longints in Linux) are used where the C versions also return an  
int, and not instead of pthread_t.

> pthreads.inc thread_t (Darwin) = pointer
>
> Result of pthread_most = cInt
> Result of ThreadManager.Killfunctions = DWord
>
> This is some serious mess. First the threadmanager functions need to
> return a signed result,

Or possibly a result depending on the OS (just like TThreadID is an  
OS-dependent type). I don't know what the Windows versions return.

> second the pointer vs cInt stuff has to be
> properly cleaned, remove thread_t from unittypes etc.

Sorry, I'm not following the last point. What do you mean with  
"unittypes"? The UnixType unit or "types used in various units"? Most  
stuff should in fact be based on pthread_t I think, since that's how  
the C declaration of those routines looks.

We could define pthread_t as TThreadID to avoid duplication of  
information though.


Jonas