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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
