I agree, the separate process is the key to prevent the app freeze.
Thanks for your input, I will post when we have finalized a method.
And again, this wouldn't be so big a deal except that you NEVER want a
paying customer to have dead software they can't use.
On Jan 23, 2009, at 5:07 PM, Alex Tweedly wrote:
Andre Garzia wrote:
we can use the load command in async mode and check the status... it
should timeout right?
right. maybe.
(remember there's a lot of speculation on my part, about this being
a DNS problem ....)
Although the load url ... with callback is intended to be non-
blocking, there may be a difficulty. I'm sure it uses sockets and
the socket async mode to be non-blocking - and I suspect the problem
is an OS call to DNSresolve() [or similar] which is happens before
the scket/TCP open, and which is blocking. Since this affects (even)
a browser, I worry it would also affect Rev - so it might just
result in a blocked process. (and even if it's not DNS, whatever it
is fails within a browser, so may fail similarly within Rev)
To feel safe, I'd want to do the network check in a separate
process, and have a fail-safe mechanism within the real app (i.e. it
detects failure rather than waiting for it). So I'd use a
backgrounded shell command which creates a temp file, and have the
real app check for that file being created/updated. Could be a ping
shell command, or a small standalone which loads a url, or anything
similar - as long as it's a separate process.
-- Alex.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
