> > I don't want to block > > Yet you're describing exactly a blocking situation: > > I would like a background thread and have the request run in there, > > using the QThreads event loop. > > The background thread runs an event loop, sure, but what is the main > thread doing in the meantime? Since it doesn't have an event loop, it > cannot receive events. The only synchronisation mechanisms left are > QWaitCondition and QSemaphore, which means the main thread must block > waiting for the background thread to finish the operation. > > You really don't have a choice besides those two. Network access is > not instantaneous. You must either use the event loop or you need to block. > > Choose one. > ----------------------------- > Blocking at the end, is ok... Blocking while the application is > running is not. Yes, I want my cake and to eat is as well :)
If you don't block, then you have a loop. Maybe you don't have Qt's event loop mechanism (QEventLoop), but you have an event loop nonetheless. Since you can't use Qt events for this and you don't want to make a blocking call, you may use a QSemaphore tryAcquire() or equivalent to check whether the work is done. But you also need to determine when your main thread's other business is done, because then you'll need to use acquire() instead and block (if you don't, you'll have a busy-wait loop). In other words, your solution is to have *both* blocking calls and a loop. > I essentially want to kick off the request at the beginning of the > run, then let the request run its course in the backround. > > If the main application (no event loop at all, non-event driven, nonQt > for the most part), finishes first (rare occasion) I can block on the > background thread ending. However most times, the single http request > will have finished long before You describe a "fire-and-forget" situation: you kick off the request and you don't care when it finishes. You'd only have to care that the application doesn't exit before the request is finished processing. However, there's no such thing as a "fire-and-forget" network request. Even the simplest request (a PUT) results in a success or failure result. I imagine your application is interested in whether the request failed, as it may need to take some action in that case. That means you need to rearchitect your application so that it can receive the communication from the other thread. So we go back to an event loop or a blocking call. Or both. -- Actually I don't care about result, even if it fails.. I understand it will return a result, but I really don't need it or want it... Honestly, if qNAM had the ability to set the timeout, I would have no problem with a blocking call.. But when the machine is off network, and can take up to 30 seconds to timeout... I cant have the application block for that long... Scott _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
