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.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
