Signals and synchronization

[canalrun]

Hello,
I am using the HTTP library to perform a Get. My code is derived from the TablesExample1.

After receiving the ResponseSuccess, I would like to set a flag or fire a signal saying the data is received rather than continuing on within this subroutine.

I tried a flag and a while-doevents loop in my main code, but this does not allow the HTTP ResponseSuccess Sub to execute.

I found the following in the Beginners Guide:

"DoEvents same, except that Erel says:
"Calling DoEvents in a loop consumes a lot of resources and it doesn't allow the system to process all waiting messages properly."

I will bet this is the problem. I have used the flag, while-doevents construct in the past for timers.

My question: Are there synchronization or signaling capabilities in B4A? I cannot find any in the documentation.

I would like to have my main routine notified that valid data has been received (or an error occurred) and continue in main from there, rather than continuing a very lengthy calculation from the ResponseSuccess Sub. What is the best way to accomplish this?

Thanks,
Barry.

 

[Erel]

Remember that unless you are using the Threading library your code is always running in the main thread (libraries code can run in other threads as well though). This means that synchronization is not really required.

Your best option is to split the calculation into several subs and then call the second sub from HttpResponse.

 

[thedesolatesoul]

I think the main routine will have to POLL the flag in a timer.
Otherwise only call the main routine from the Response sub.

What you are looking for seems to be semaphore, or a blocking statement.
That will be hard to implement in B4A. (Msgbox is a blocking statement).
Or maybe show a modal dialog, and remove it on receipt of the response.

EDIT: Didnt realise Erel beat me to it!

 

[canalrun]

Thanks both.

It's just my coding style - I like to keep very shallow levels of subroutines (and methods)

Barry.

 

[thedesolatesoul]

This does raise a question in my mind though.
What happens if you start a service (which should run on a different thread) and then display a modal dialog (like a msgbox).
When the service completes its run and callsubs back to the main activity, the main activity is blocked due to the msgbox? Will the callsub be ignored?

 

[agraham]

Services run on the main thread of the process just like activities but cannot manipulate UI elements, including message boxes.

 

[thedesolatesoul]

Services run on the main thread of the process just like activities but cannot manipulate UI elements, including message boxes.

If services run on the main thread, then what happens if the main activity is busy with something else (maybe even a modal dialog) and the service needs to start due to StartServiceAt at some time? Will it be stalled?

 

[agraham]

Erel might know the definitive answer but I suspect not as the message box modal mechanism pumps the message queue and so may allow the the service Subs to be called in response to system messages.

 

[thedesolatesoul]

Erel might know the definitive answer but I suspect not as the message box modal mechanism pumps the message queue and so may allow the the service Subs to be called in response to system messages.

Initially I thought Services run on a different thread. so I thought they would not block the main UI thread. I need to rethink my strategy to make sure that does not happen.

 

[Erel]

As agraham wrote services run in the same thread. If the thread is blocked then the service will only start once the main thread is available.
Modal dialogs do not block the main thread, and if I remember correctly services should be able to start properly when a modal dialog is displayed.

You should never block the main thread as Android will kill your application after about 5 seconds (showing "application not responding" message).