Konrad Rosenbaum wrote: Hi,
I see I'm not the only one accepting the fact that when dealing with event- driven GUIs having a human-in-the-loop one rather quickly reaches a stage where it becomes hard to guarantee anything (with all that implies for writing code that handles unforeseen situations *gracefully*). > crashes. When dealing with threads and signals between them determinism > flies out the window and the tiniest change in timing can change behavior > radically. No kidding (I'm used to working on/with older hardware or simply stressing it and seeing all kinds of things no one else can apparently reproduce.) As I said, the crashes I saw were not to do inappropriate signal/slot programming but to me not understanding something in "wildcard" capturing for lambdas. IOW, the crash frequency has been 0 ever since I fixed that (the capture, not my understanding :)) > Whenever a QueuedConnection triggers the sending object generates an event > and delivers it to the event queue of the thread that owns the target slot's So the sending object knows that the nature of each connection to it? >> Can I assume >> there's some kind of fifo that ensures signals are delivered in order of > > Never assume order. Ok. From your other reactions I infer there is something like a mostly-fifo with a mutex that protects pushing and popping :) > deterministic or in order. Threads execute in a (seemingly) random order and > can interrupt or race each other. And one cannot even rely on mutexes to "fix" or prevent that? > important or less important than others - e.g. the deleteLater event is > normally only handled at the top level of the event loop to prevent crashes > caused by less then absolutely ingenious programmers using QueuedConnection, > deleteLater and QEventLoop (that fact saved my bacon a few times). Sounds like the situation that ObjC/Apple addressed by using refcounting instead of direct deletion. Anyway, order isn't crucial in the particular application I'm working on here. The only thing that matters is that signals are delivered in an acceptable time- frame after having been sent. And that should be the case (my initial reason for getting involved with this was to keep the main event loop from being blocked). R. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
