Richard,
You could always write yourself a curl wrapper... just sayin'.
Phil Davis
On 9/2/16 9:28 AM, Richard Gaskin wrote:
Charles Warwick wrote:
> I would like to resolve as many libUrl reliability issues as possible
> in the community edition as well.
>
> Having worked on the tsNet libUrl wrapper, I have some ideas about
> what is going on but what always helps is a sample script that can
> reproduce the problem.
Thanks for your interest. I've modded my libURL and have been
experimenting, will deliver a sample stack soon.
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.
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.
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.
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.
--
Phil Davis
_______________________________________________
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
