[Interest] QNetworkAccessManager in a command line, non-eventloop application

[Thiago Macieira]

On sexta-feira, 18 de janeiro de 2013 17.08.46, Scott Aron Bloom wrote:
> On sexta-feira, 18 de janeiro de 2013 01.49.35, Scott Aron Bloom wrote:
> > 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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130119/8aae4ae5/attachment.sig>