libURL gone mad

[Charles Warwick]

Hi Richard,

On 3/09/2016 2:28 am, Richard Gaskin wrote:
>
> Thus far I've found that your libURL function is much more reliable 
> than the recommended flag option, but still problematic in some cases 
> unless I slow things down with the introduction of an 
> otherwise-unnecessary wait.
>
Interesting.  I would like to see an example of this, so that I can see 
if this issue is actually a bug.
> Chipp Walters uses a brute-force method since picked up by Jacque and 
> others in which he calls libURL in a repeat loop until it returns a 
> meaningful result.  Sad to have to work that hard.
>
> At the heart of why so many people seem to be having problems with 
> libURL is that the so-called "blocking" form only blocks the current 
> execution instance of the handler calling libURL. Messages still 
> happen, any handlers that are calling libURL are re-entrant, and 
> that's where people are seeing blocked connections, engine hangs, and 
> occasional cursor locking (WTH is up with that?).
>
> The ideal solution would be for an option to have true blocking, 
> without the semi-quasi-difficult-to-predict-exactly-what's-happening 
> form of threading in place for the so-called "blocking" form offered 
> currently.
>
If I understand correctly what you are after, how about just arbitrating 
the network requests yourself and then the issue would go away entirely.

For example, use some code like this:

local lRequestArray, lRequestSent

on mouseUp
    put the number of lines of (the keys of lRequestArray) into tIndex
    add 1 to tIndex
    put "https://www.google.com/" into lRequestArray[tIndex]
    send "sendRequest" && tIndex to me in 0 milliseconds
end mouseUp

on sendRequest pIndex
    if lRequestSent is not 1 then
       put 1 into lRequestSent
       put URL lRequestArray[pIndex] & cr after field 1
       delete local lRequestArray[pIndex]
       put the keys of lRequestArray into tKeys
       if the number of lines of tKeys is not 0 then
          send "sendRequest" && line 1 of tKeys to me in 0 milliseconds
       end if
       put 0 into lRequestSent
    end if
end sendRequest

This will ensure that only one request is sent at a time and that if the 
mouseUp handler is fired multiple times before the first request is 
completed, any additional requests will be queued and executed as soon 
as they can be.

It could easily be adapted to include a "method" parameter and even a 
"targetVariable" parameter to the sendRequest handler so that it could 
be used for all network requests in your application.

> Those who need non-blocking can use "load url".  Works fine, at least 
> for GET.
>
> Maybe the issue is that POST doesn't currently have a non-blocking 
> form, so the design in place now attempts to hit some mystifying 
> middle path between true blocking and truly async behavior, hitting 
> neither quit spot-on.

As I am sure you are aware, the tsNet external provides non-blocking 
(async) POST, along with non-blocking versions of every other request 
type that it supports.

Implementing your handler in a non-blocking manner would be another 
alternative to the above example.

>
> I'll continue my experiments with various permutions, including 
> Chipp's now-famous hammer-on-it-until-it-behaves option, and see if I 
> can come up with something that doesn't require slowing down the 
> workflow with an otherwise-unnecessary wait statement.
>
> It's not a long wait (right now the shortest wait that prevent hangs 
> is around 250 ms), but the issue of preventing re-entrance remains a 
> challenge.
>
> I may wind up keeping a checksum hash of the url + POST data, 
> monitored in a timer to prevent duplicate attempts from happening too 
> close together.   Seems a lot of work, though, for something where the 
> code would be MUCH simpler if we only have a truly blocking GET and 
> POST option.
>

A variation of the above code could possibly be added to the libUrl 
library to provide these options.  I will contemplate this a bit 
further. :-)

Hope that helps,

Cheers,

Charles