Hi,

I got most of my Thread Manager demo written. While trying out a few features I noticed that every time as Suspend a thread, my app is killed. Running it through gdb I get the following output.

------------------------------------------
(gdb) run
Starting program: /home/graemeg/programming/threadmanager/MultiThreadDemo [Thread debugging using libthread_db enabled]
[New Thread -1213503280 (LWP 8412)]
[New Thread -1216353392 (LWP 8417)]

Program received signal SIGSTOP, Stopped (signal). [Switching to Thread -1216353392 (LWP 8417)]
0x080633c1 in SYSTEM_FPSYSCALL$LONGINT$LONGINT$LONGINT$$LONGINT () (gdb)
------------------------------------------

I'm using FPC 2.1.3 (r7222) under Linux (2.6.20-16-generic kernel) on a Intel P4 processor. Any ideas?

Graeme Geldenhuys wrote

I got most of my Thread Manager demo written. While trying out a few features I noticed that every time as Suspend a thread, my app is killed. Running it through gdb I get the following output.

I don't see it being killed from your output, or am I missing something ?

man 7 signal:

SIGSTOP 17,19,23 Stop Stop process

It stops ... and that's what you asked it to do.

Micha

The GUI in frozen after that. Unresponsive, doesn't repaint, etc... I have to kill it with 'xkill' and click on the form.

If I run the app it from the console (not via gdb) as such...

$> ./MultiTheadDemo

It doesn't return to the prompt while the app is running, which is correct. I didn't specify the ' &' at the end. But as soon as I Suspend a thread, it returns me to the prompt! Why??? And the GUI is still showing, but frozen.

If it helps, I can archive the demo and post it to the mailing list (though it requires Lazarus LCL).

Regards,
- Graeme -

Graeme Geldenhuys wrote

The GUI in frozen after that. Unresponsive, doesn't repaint, etc... I have to kill it with 'xkill' and click on the form.

No, you can also type "fg" to let the process continue.

But as soon as I Suspend a thread, it returns me to the prompt! Why???

Because sending pthread_kill(SIGSTOP) to a particular thread apparently has to freeze the entire the process on posix-compliant systems, and not just the target thread. Early Linuxthreads implementations did not implement this properly and only stopped the targeted thread, but this has been fixed in NPTL.

There is no portable way to suspend a thread at an arbitrary point under *nix, see
http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#E

(question E.4)

And the reason for that is probably the other thing that's mentioned there:

"Notice that thr_suspend() is inherently dangerous and prone to race conditions. For one thing, there is no control on where the target thread stops: it can very well be stopped in the middle of a critical section, while holding mutexes. Also, there is no guarantee on when the target thread will actually stop. For these reasons, you'd be much better off using mutexes and conditions instead. The only situations that really require the ability to suspend a thread are debuggers and some kind of garbage collectors."

Of course, since Windows provides such functionality, people nevertheless depend on this. But when creating cross-platform code, it's clearly a very bad idea (and several of the caveats mentioned above can of course also hold true under Windows).

I will remove the pthread_kill(SIGSTOP) from the RTL, since it obviously does not do what people expect it to do.

Jonas

Jonas Maebe wrote

Of course, since Windows provides such functionality, people nevertheless depend on this. But when creating cross-platform code, it's clearly a very bad idea (and several of the caveats mentioned above can of course also hold true under Windows).

FWIW, similar functionality was also removed from Java after a while. Sun wrote an article explaining why this was done: http://java.sun.com/j2se/1.4.2/docs/guide/misc/
threadPrimitiveDeprecation.html

Jonas

Jonas Maebe wrote

> The GUI in frozen after that. Unresponsive, doesn't repaint, etc... I > have to kill it with 'xkill' and click on the form. No, you can also type "fg" to let the process continue.

Ah, that worked yes...

After my post, I google'd some more and found a similar article explaining the change in Linuxthreads.

There is no portable way to suspend a thread at an arbitrary point under *nix, see http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#E

Okay that makes sense. I guess my Thread Manager did actually teach me something then. :-) Don't use .Suspend
I'll rework the Thread Manager example. The Java link you sent came in handle and it explains it very well and shows you what alternative to use.

Thanks Jonas.

Graeme.

Graeme Geldenhuys wrote

Okay that makes sense. I guess my Thread Manager did actually teach me something then. :-) Don't use .Suspend

Just to clarify: don't use .Suspend on another thread. Suspending yourself and letting someone else wake you up again is no problem.

Jonas

Except that it doesn't work on Linux.

Michael.

It should, that uses plain semaphores.

Jonas

Michael Van Canneyt wrote

> Just to clarify: don't use .Suspend on another thread. Suspending yourself and > letting someone else wake you up again is no problem. Except that it doesn't work on Linux.

Nope, that works fine here! My worker thread counts down from 10 to
0. I called suspend when the counter reached 5.

Resumed the worker thread from the GUI thread and it continued counting to 0.

Regard,
- Graeme -

Excellent, then :-)

I wrongly assumed it still used the old STOP/CONTINUE signal method. My apologies.

Michael.