Can't abort a createInputStream

#1


I'm trying to cancel a createInputStream using the OpenStreamProgressCallback.
I was expecting that returning false from OpenStreamProgressCallback would abort, but it does not work.
actually, the returned value of the callback is never checked in URLConnectionState::start() (i just checked on Mac)


Shouldn't it be changed to something like that ? Or isn't it made for that?

    bool start (URL::OpenStreamProgressCallback* callback, void* context)
    {
        startThread();

        while (isThreadRunning() && ! initialised)
        {
            if (callback != nullptr)
            {
                if (! callback (context, latestTotalBytes, (int) [[request HTTPBody] length]))
                {
                    stop();
                    break;
                }
            }

            Thread::sleep (1);
        }

        return connection != nil && ! hasFailed;
    }
#2

To clarify, I was expecting that returning false from the callback would abort the createInputStream() because of that comment in the doc :

   /** This callback function can be used by the createInputStream() method.
       It allows your app to receive progress updates during a lengthy POST operation. If you
        want to continue the operation, this should return true, or false to abort.
    */
    typedef bool (OpenStreamProgressCallback) (void* context, int bytesSent, int totalBytes);

I'm in a case where I want to abort the createInputStream from the callback before it ends because my threadShouldExit()

#3

Any chance to get this possibility to abort a createInputString with the OpenStreamProgressCallback working?
or am I having a wrong approach and misinterpreting the use of OpenStreamProgressCallback??

#4

Sorry, yes, that is how it's supposed to work, and it's just on OSX where it doesn't (because of the way OSX handles this stuff internally).

But the current OSX implementation uses some deprecated APIs, and I've got a half-finished re-implementation of it in the works. When that's finished, I'll check that this works, but until then there's no point in us trying to fix the current code.

#5

ok, I understand, but if you don't add a workaround, please write in the documentation that this does not work. it's a pity that we are loosing some time encountering "known bugs"

#6

Sorry, didn't know it was broken!

#7

Is that bug still there? any plan to fix it or approximate date for the new implementation release?

#8

Sorry, yes, it's still in our backlog. Will get onto it when poss..

#9

I’m a bit sad this bug hasn’t been fixed in the last ‘releases’.
how far away is that in the backlog now? :slight_smile:

#10

Yeah, sorry, this one kept getting bounced… I have a branch with a half-finished implementation that I keep meaning to go back to and finish…

#11

Sorry to come back to this, but the bug is there since 4 months, so again, if you don’t add a workaround, why not adding a warning in the documentation saying that this does not work/is not implemented ?

Is the solution I posted in the first post (adding the check of the value returned by the callback) that terrible?

#12

any news? :slight_smile:

#13

We released the updated version using the new APIs a while ago, IIRC.

#14

But it seems you still do not check the return value of the callback ?

#15

So, can’t you check the value returned by the callback?
Sorry for being pushy, but it’s been almost 6 months now…

#16

Yes, sorry we didn’t spot that one - will get it sorted out today!