Hi.
I use CURLSMBS to download an update file.
While downloading, timers and invalidates don’t happen.
The docs say use .YieldTime = true
This makes no difference - the docs also say
Seems like in RB 2009 this property only has effect if you run CURL in a thread.
Is that still the case? Im using a mix of Xojo 2015/8/21 and no effect…
Is your update code in a thread?
Well no… this is kinda the point.
14 years ago this was a ‘known issue’.
We aren’t in 2009 any more…looks like it is still unfixed.
I don’t really want to have to refactor into a thread.
In fact, if it WAS in a thread, I wouldn’t expect to have to use the YieldTime at all… it’s in a thread…
There is nothing to fix. You can’t run code on the main thread and expect other code on the main thread to run at the same time.
If you don’t want to use a thread (best solution IMO), you could maybe use CURLSMultiMBS to start the transfer and then poll it using a timer.
Yet there are ‘Progress’ events, during which it is reasonable to expect I could update something.
Oh well.
Docs: (my bold)
You can run CURL from a thread to download several things at the same time or keep the GUI more responsive. For better GUI, you can even call a method like app.DoEvents to get the GUI updated more often.
Guess it’s just not quite…
maybe use CURLSMultiMBS
I’ll give it a try.
IIRC this (for whatever reasons) didn’t offer much improvement for me, which is why I’ve switched to using CURLSMultiMBS in a thread for almost all my transfers.
Well, it depends on how many transfers you run.
One or two background transfers with threads is fine.
But if you run 10 parallel things, CURLSMultiMBS is much more efficient. Basically you add your transfer to the queue, then have a timer perform every 10ms and get an event whenever one of the transfers finishes.
Thanks, I will revisit this.
I would say not only in this case. I maintain a desktop app that keeps a connection to a web server. Not much parallel communication, but a lot of handshaking going on.
Switching from URLConnection to CurlSMultiMBS made that process much snappier. I can see in the debug log quite often used channels being reused, reducing their negotiations recognisably.
So you’re saying we should have one singleton CURLSMultiMBS in the project, and when we have a new transfer to make, we instantiate a new CURLMBS and call CURLSMultiMBS.addCURL, passing the newly-instantiated CURLMBS?
The docs say of addCURL only “Add a standard CURL handle to the multi stack.” which is not very informative.
Yes, one multi object (technically you can have multiple, but one is enough).
Then instead of calling Perform on the curl handle, you pass the CURL object to the multi handle for the queue. Multihandle will do several in parallel, but also queue up more if you have more.
Later you can get an event if one of them is finished in either the CURL or the CURLMulti object:
So you can process results asynchronously.
OK, I’ve been doing it all wrong for a long time 