jonas.maebe at elis.ugent.be
Wed Nov 8 10:35:01 CET 2006
On 8 nov 2006, at 10:05, Michael Schnell wrote:
>> Does anyone see a problem with the following CSuspendThread/
>> CResumeThread implementations?
> 1) This of course is the Linux version.
No, it's the generic *nix version (i.e., also used for Free/Net/
OpenBSD, Darwin and Solaris).
> Are the other implementation already in place so that the result is
> platform independent ?
I don't know.
> 2) In Linux we have the old ("Linux thread" -> each thread is a
> process) and the new Posix compatible "Kernel-Thread"
> implementation (as of Kernel 2.6, a Linux process can have multiple
> threads). I don't know if/how TThread can select which kind of
> threads are created. AFAIK, using the standard thread library,
> Kilix automatically uses the new threads with Kernel 2.6, while
> still using the old ones with Kernel 2.4.
We also use the standard thread library.
> As I feel that using the new Kernel-Thread way is highly
> recommended, it should be granted that TThread uses same (when
> running in 2.6) and that the "suspend" method is workable with both.
pthread_kill is defined as sending a signal to a particular thread.
> If I remember correctly, there is a signal handler per process and
> not per thread, so this _might_ be a problem.
That's why I use pthread_kill and not kill, as it's defined as
sending a signal to a particular thread. If the Linux pthreads
library does not handle this correctly, it's a bug in the Linux
pthreads library. If you know another way to suspend a thread from
inside another thread, feel free to say how that can be done.
The previous Linux code used plain kill which is wrong anyway (and
the others mentioned above didn't do anything whatsoever), so this is
at least an improvement.
More information about the fpc-devel