Discussion about "Threads, Events and QObjects" article
-
[quote author="Gerolf Reinwardt" date="1292356379"]bq. What do you mean? Right now there’s a simple example by an hypotetic recursion into a slot. Do you think I should stressing on it even more?
I meant that it can not only fore recursion, it can also fore a stutdown or delete of an object, that you currently work on. Think of deleteLater, which is executed by the event loop. This can happen when you call @QApplication::processEvents@. And then, perhaps, an object, where yiou think it exists, is away. And I saw suxgh tghings, especially not recursions but unexpected object deletion which result in a crash. And then all you get is:
bq. It crashes, I don't know why, but here the memory is freed.....And you are the happy person to find the bug, they introduced by spinning the event loop out of scope...
So I would make a bigger note with many exclamation marks and warnings... :-))[/quote]
Ok, I got it now :-)
Well, I've integrated your suggestions here and there. Give it a read if you want to :)
[quote author="chetankjain" date="1292393650"]moving this to Wiki forum, thats the right place to initiate discussions on wiki articles[/quote]
Ops! You're right, sorry about that.
-
bq. how to start, stop, join a thread under (at least) one major operating system;
Is joining threads such a common pattern?
I've always imagined threads as autonomous agents. This I was able to produce programmatically and at some point they were finished and forgotten. Whether or not the program code orphaned never seemed to matter to me. -
[quote author="Wolf P." date="1292845577"]bq. how to start, stop, join a thread under (at least) one major operating system;
Is joining threads such a common pattern?
I've always imagined threads as autonomous agents. This I was able to produce programmatically and at some point they were finished and forgotten. Whether or not the program code orphaned never seemed to matter to me.[/quote]It's a pattern, that's all. For instance, a possible use case is telling a worker thread to finish, then actually wait for it to end (by joining it), then deallocate some resources used by it.
-
[quote author="Wolf P." date="1292847084"]Gerolf, I see. The somewhat outdated framework I worked with, provided only the forking.
Do you know a good real-world example?Peppe, as I see, to join means simply to wait?[/quote]
I was pretty sure it was standard lexicon when it comes to threading: it means "block the calling thread until the target thread terminates"; and yes, it's what QThread::wait() does. See for instance:
http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_join.3.html
http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#join()
http://perldoc.perl.org/threads.html#DESCRIPTIONNow that you're telling me, perhaps should I change that term?
-
-
Sorry for this naive comment. Finally I found that this is Qt terminology: http://doc.qt.nokia.com/latest/threads-reentrancy.html
-
It is not just Qt terminology. It's general programming terminology and something everyone who does at least the slightest bit of multi-threading should know about.
http://en.wikipedia.org/wiki/Reentrant_(subroutine)
http://en.wikipedia.org/wiki/Thread_safety -
[quote author="Franzk" date="1292858262"]...and something everyone who does at least the slightest bit of multi-threading should know about.[/quote] thx for the WP references :)
BTW: I did some multithreaded coding without problems, and without thinking about reentrance.
-
To be honest, the little problem is that there might be some confusion due to literature and/or other toolkits. That's why I specified that in the article I follow the Qt conventions; anyway, I added a link to http://doc.qt.nokia.com/latest/threads-reentrancy.html, just to make it even more clear :-)