URL::read...() functions block calling thread

General JUCE discussion
1

The functions URL::readEntireBinaryStream() and URL::readEntireTextStream() look handy but block the calling thread.  Is it the intention that these are generally called from a worker thread to avoid holding up the UI?

If the answer to the above is yes, I'm a bit confused why the Mac version of these functions uses a worker thread (in URLConnectionState) only to have the calling thread spin waiting for its completion.

Shouldn't it be:

- URL::read..() is blocking -> app may call it on worker thread to make it async -> no need for extra worker thread in URLConnectionState

OR

- URL::read..() is async -> app may spin for completion to make it blocking -> extra worker thread needed in URLConnectionState

Currently it seems to be the worst of both worlds.  Now the disclaimer : my knowledge of networky stuff is poor!

 

2

Yes, the intention is that you'd use a thread for them.

The fact that the OSX version uses another thread internally is just an implementation detail - I forget why, but there was some reason why it mattered (maybe something to do with the event thread being used by it somehow).

3

OK makes sense, thanks.