workaround_timeout_bug?

General JUCE discussion
1

Jules,

It looks like I’m bumping into threading issues because my internet connections don’t want to time out (win7)…
Now I just bumped into your WORKAROUND_TIMEOUT_BUG define, but haven’t found any references to it anywhere on the forum…
Could you give me some more info?
When should this be defined, when shouldn’t it??

  • bram
2

It was a few years ago and I don’t remember all the details, but there was some kind of bug in the win32 internet stuff that I was trying to avoid by making it time-out manually. It was experimental though, I don’t think I left it enabled, but feel free to try it.

3

Actually, even when WORKAROUND_TIMEOUT_BUG=1 I still don’t get the timeout I want…

I have a thread that does an HTTP post, I made my server super slow (for testing) and when I do my POST my timeout is not respected…

I.e. when I do this:

[code]MyThread thread;

thread.startThread();

run()
{
…
url.createInputStream(true, nullptr, nullptr, String::empty, 500, &responseHeaders)
}

thread.stopThread(5000);
[/code]

I consistently get into stopThread’s “very bad karma if this point is reached” assertion failure…

  • bram
4

I’ll make you a quick test to reproduce this…

  • bram
5

[quote=“bdejong”]
I consistently get into stopThread’s “very bad karma if this point is reached” assertion failure…

  • bram[/quote]

Yeah, I think that I added it as a bit of a emergency fallback way of timing out. There’s probably a better way of cleanly making the win32 stuff time-out, but I never found it. (But MS might even have fixed or updated the APIs since I looked at it)

6

Mmm, but then how do I get past this in debug mode? :-S
I know the thread will be killing itself badly…!

  • bram
7

Sorry, don’t really have an answer to that.

8

Found it, it’s not the “connection” that times out, it’s the data sending that times out…
It’s a bit of a mess when it comes to the timeout, but this is a bit of a hacky solution:

        InternetSetOption (sessionHandle, INTERNET_OPTION_CONNECT_TIMEOUT, &timeOutMs, sizeof (timeOutMs));
        InternetSetOption( sessionHandle, INTERNET_OPTION_RECEIVE_TIMEOUT, &timeOutMs, sizeof (timeOutMs) );
        InternetSetOption( sessionHandle, INTERNET_OPTION_SEND_TIMEOUT, &timeOutMs, sizeof (timeOutMs) );
        InternetSetOption( sessionHandle, INTERNET_OPTION_DATA_RECEIVE_TIMEOUT, &timeOutMs, sizeof (timeOutMs) );
        InternetSetOption( sessionHandle, INTERNET_OPTION_DATA_SEND_TIMEOUT, &timeOutMs, sizeof (timeOutMs) );

It’s a bit of a hack as each of these calls can now take “up to timeOutMs” so in total you would get a possible timeout of timeOutMs*5, but maybe you know a nicer solution to that than me…
It could be solved by ripping the URL getting in two, one for the actual connecting, the second for the sending/getting of data with different timeouts…

  • bram
9

(also works without the presence of the WORKAROUND_TIMEOUT_BUG preprocessor directive)

10

Ah and if you want to test:

#include "../JuceLibraryCode/JuceHeader.h"

class UrlGetThread : public Thread
{
public:
    UrlGetThread() : Thread("Get me a url!") {};
    virtual ~UrlGetThread() {};

    virtual void run() 
    {
        URL url = URL("https://activation-staging.samplesumo.com/juce_slow/");

        DBG("Before create input stream");

        ScopedPointer<InputStream> inputStream(url.createInputStream(false, nullptr, nullptr, String::empty, 500));

        DBG("After create input stream");

        if (inputStream)
        {
            String stream = inputStream->readEntireStreamAsString();
            DBG(stream);
        }
        else
        {
            DBG("Stream was 0");
        }
    }
};

//==============================================================================
int main (int argc, char* argv[])
{
    UrlGetThread thread;
    thread.startThread();
    thread.stopThread(2000);
    return 0;
}
11

Ah, nice! I think that’ll be a better solution than my old hack - I’ll tidy that up. (Always nice to be able to remove a hack!)