Konrad Rosenbaum wrote:
>> And one cannot even rely on mutexes to "fix" or prevent that? > > If you use Mutexes right you can rely on them to serialize the code that > blocks on the same Mutex, i.e. only one blocking code block is executed at > the same time. <snip> > Depending on hardware timings and bus congestion these > threads may race each other. Hmm, ok. Nothing new here in fact, but thanks :) >> Sounds like the situation that ObjC/Apple addressed by using refcounting > > If by "problem" you mean programmer stupidity (or if you prefer: naturally > limited cognitive capacity): yes. ;-) Heh. Let's go for the latter, with capacity determined over all brains working on a given project. > If by "acceptable" you mean "fast enough for a human being", then yes - > QueuedConnection will do this for you reliably enough. Careful, "for the task at hand" always implies "for a human being" (at least the one who defined the task) but that doesn't mean a human could resolve the difference between just enough and just not enough (directly, that is) ;) > Do not make any assumptions about the order of signals or slots. Try to > avoid the assumption that a signal only returns after the slot has been > executed (or that it returns immediately) That one is easy - I've never seen any user-written code that corresponds to the signal function, so I've always thought of it as raising a system signal. R. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
