[fpc-devel]promised tthread patch

[Michael.VanCanneyt at Wisa.be]

On Sun, 16 Nov 2003, Pedro Lopez-Cabanillas wrote:

> Michael.VanCanneyt at Wisa.be wrote:
> > On Sat, 15 Nov 2003, KJK::Hyperion wrote:
> > > At 12.27 15/11/2003, you wrote:
> > > >All you need to do is send the STOP signal to the thread.
> > >
> > > This is a common misunderstanding. I quote from IEEE 1003.1:
> > >
> > > "[...]
> > >
> > > Note that pthread_kill() only causes the signal to be handled in the
> > > context of the given thread; the signal action (termination or stopping)
> > > affects the process as a whole.
> > >
> > > [...]"
> >
> > Strange. How do you explain that Kylix uses it ? I've used threads in
> > Kylix, and they definitely work with suspend... Probably because for linux,
> > each thread is a different process anyway ? (at least till the 2.4 kernels)
> 
> Red Hat has already backported the new NPT to 2.4, and it is included in RH9  
> IIRC. 

I work with SuSE :-)

> You can expect that Kylix multithreaded programs won't work very well 
> under RH9 and newer Linux distributions, if they use TThread.Suspend and 
> TThread.Resume (implemented using the signals SIGSTOP and SIGCONT). Borland 
> shows little interest on Kylix updates, giving to the competitors a  good 
> chance to increase market share ;-)
> 
> It is on-topic a little citation of the announcement of Native POSIX Thread 
> Library. The complete article can be found here:
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=3D8A6EC1.1010809%40redhat.com&rnum=1

OK, thanks, this cleared up some stuff. Seems that another way will be
needed. If it will be possible at all. I don't see how if you can't have
per-thread signal handling...

I don't think this is a change for the better, but who am I to say so...

Michael.