DoEvents in Web Apps for tight loops?

I would like to make a Xojo.Net.HTTPSocket subclass work synchronously in a stand-alone Web App. I intend to use a tight loop in an added method that returns after waiting for the PageReceived event to set an added property with reply content from a Post.

Do I use DoEvents in the tight loop? The DoEvents documentation appears to be silent concerning Web Apps.

[quote=192186:@Eric Wilson]I would like to make a Xojo.Net.HTTPSocket subclass work synchronously in a stand-alone Web App. I intend to use a tight loop in an added method that returns after waiting for the PageReceived event to set an added property with reply content from a Post.

Do I use DoEvents in the tight loop? The DoEvents documentation appears to be silent concerning Web Apps.[/quote]

Whether or not you use doevents, you may want to ask yourself why you want to transform an intrinsically event driven asynchronous control into a pseudo synchronous by polling its PageReceived event.

If you want synchronous, use regular HTTPSocket in synchronous mode.

If you absolutely need Xojo.Net.HTTPSocket, for instance because you need HTTP 1.1, you might as well try to wrap your head around event driven programming. The end result between using a tight loop to monitor an event, and simply using the event handler is the same, except with your polling all you get is unnecessary code.

Make it easy on yourself. Trying to push a cube into a round hole is futile.

An event driven model spanning asynchronous communications does not necessarily work well in every situation. In this case, the complexity and cost in dev time and compute power of analyzing and reordering different requests sent asynchronously far exceeds the simplicity of sending the requests one at a time. Broadly speaking processing can commence upon receipt of each file if sent serially whereas the processor remains idle when all files are sent at once and then would max out when they all arrive at once.

Also, the HTTP 1.1 implementation seems to have better security features.

So are DoEvents stable and effective in Web Apps for tight loops?

DoEvents should be not be used outside of console apps. They seriously interfere with the event loop.

Thanks Bob,

I had read somewhere that Web Apps were a type of console app but upon reflection that couldn’t be so if events are being transferred from the browser for server-side execution. In that case using a low priority thread with sleeps in a tight loop (located outside the HTTPSocket subclass) seems to be the way to go. Does that sound right?

Have you tried it? Because this shouldn’t happen. You should receive them in individual events and then queue them for processing. I don’t see how that would differ from what you propose.

Web apps are basically console apps, but I do not know if DoEvents is good or bad for the event framework used in web. It’s definitely bad in desktop.

I tend to agree with Michel that designing a solution around events is better, but assuming you cannot do this due to the complexity of existing code…yes, running the code in a thread so that your polling loop can sleep is one way to solve this.

Bottom line, you should never run more than one event loop. Sure, web apps are console apps, but they already implement an event loop, so DoEvents is out. You could get into the same trouble with a normal console app where you use DoEvents incorrectly as well.

Actually, thinking about it, HTTPSocket (non Xojo.Net) actually stops execution until the page has finished downloading. That is the reason why it has a TimeOut property. So emulating it with a tight loop and no doevents would just do the same.

In the old framework, using a version of Get or Post that takes the Timeout parameter will cause the socket to download synchronously and block. DoEvents can’t help here in any case because you’ll only reach a loop or DoEvents call after the socket method has completed.

In the new framework it looks like there’s only one asynchronous call, Send.

With an asynchronous method you can have properties that are set by the events, and ‘poll’ those properties with a loop that checks them and sleeps. From a Thread this should not block or even waste too many CPU cycles so long as you set the sleep time properly.

Correct.

You’re probably right on this, and I would recommend a Thread over DoEvents any day, but it is possible to have a ‘do events’ type function merely yield control back to a single event loop or processor. In that case it’s not necessarily a bad call like it is in desktop apps.

But I think you’re right and it’s implemented in a similar fashion across all targets, making it a very bad “solution” here.

Thanks everyone, I think I’m on the right track now with a thread…

I have ruled out creating queue at the receiving end because data sent first will not necessarily arrive first if the later data is shorter and I don’t want to spend dev time and maintenance cost on code that reorders the data upon receipt. Sometimes such asynchronous transmission could delay processing of the received data too. Sending data using multiple requests would also presumably invoke a lot of context switching and could potentially cause network spikes over slower links.

Thanks again,

Eric

[quote=192295:@Eric Wilson]Thanks everyone, I think I’m on the right track now with a thread…

I have ruled out creating queue at the receiving end because data sent first will not necessarily arrive first if the later data is shorter and I don’t want to spend dev time and maintenance cost on code that reorders the data upon receipt. Sometimes such asynchronous transmission could delay processing of the received data too. Sending data using multiple requests would also presumably invoke a lot of context switching and could potentially cause network spikes over slower links.[/quote]

The way to avoid collisions in an asynchronous setup is simply to initiate subsequent send requests in the PageReceived event. All that requires is to use a queue. If you think about it, it becomes pretty equivalent in terms of response time to a series of synchronous requests.

Exactly

Looks feasible but is recursive and adds a socket to the stack with each Post. Is this safe?

No need to add any new socket. Since the previous request has ended with PageReceived, you are free to initiate a new request in the socket where the event took place.

Thanks Michel, but all this should still be in a thread otherwise the instance of the web app will be hung up until done?

I found I needed to trigger a timer to get serial requests working, just a single shot 1ms timer will do. The socket was throwing an exception, but I can’t remember what it was - something to do with the state of the connection.

No. Asynchronous Socket does not hang the UI. That is all the beauty of it. You can think of it as having a thread built in :slight_smile:

I never experienced that but since Mac and Windows have different behavior, it is possible that in Windows the PageReceived event needs to have terminated to actually release the socket. Using a timer to initiate the new request would effectively do that. That is probably a good precaution.