B4J Question I am looking for the right waiting method without blocking?

[T201016]

Hi,
I want to wait for the (Shell) to finish saving to the .mp4 file before I go to further instructions for creating another video file.
I do it this way:

Do Until FileWatcher.IsReadable(FullPath)
    Sleep(100)
Loop
'Start to the next code line.

The above way seems to be good, but I noticed that sometimes it can turn on the line (to Until ... Loop)
Only half of them save per 100 files. What could be the cause? Too short set time for Filewatcher?

 

[emexes]

Three maybe fixes:

1/ after the loop, double-check that the file is still readable
2/ add a short sleep before and after 1/
3/ don't use the same filename each time (or maybe you're already not - I can't tell from the code you've given)

The technique of using a polling loop with a sleep inside it is one that Erel has used, so you're in good company.

[B4X] Wait for multiple tasks to complete

A pattern such as this one can be used when you want to run multiple resumable subs concurrently and wait for all of them to complete before continuing: Dim status(1) As Int Test1(status) Test2(status) Test3(status) Do While status(0) < 3 Sleep(50) Loop...

www.b4x.com

 

[walt61]

How about using

Dim shl As Shell
'...
shl.RunSynchronous(-1)

?

 

[T201016]

Hi @emexes, @walt61
Assuming that I tried to slow down the operation of several hundred SHELL startups and finish displaying the window with a message only after the last launch of Shell. I managed to do it HERE:
Answer to the question @walt61: I use shl.RunSynchronous(-1)
Thank you for your support

 

[walt61]

I tried to strive to slow down the operation of several hundred SHELL startups, and finish displaying the window with a message only after the last start of the Shell

If you use RunSynchronous, your code waits for the shell to complete, so you'd only be running one at a time, and can then show the completion message after your loop. No need for asynchronous shenanigans like Wait For in that case

 

[T201016]

If you use Ruszynchronous, your code is waiting for the end of the coating, so you will start only one at once, and then you can display the message about the end after the loop. In this case, there is no need to use asynchronous tricks such as Wait for

Good idea,

 

[walt61]

I'm afraid my Polish is a bit rusty, but Google tells me 'Dobra sugestia' means 'good suggestion'

 

[T201016]

I'm afraid my Polish is a bit rusty, but Google tells me 'Dobra sugestia' means 'good suggestion'

Google translator can sometimes create tricks
As for thread #3: shl.runsynchronous (-1) in my code disk performance has not improved.

 

[DonManfred]

I don´t see how running anything in shell could increase disk perfomance.
Probably the disc (pc) is just that slow.

 

[emexes]

performance has not improved

Performance in what sense?

Speed?

Or proportion saved?

Only half of them save per 100 files.

 

[emexes]

Performance in what sense?

Remember the three stages of computer program optimisation:

first make it work
then make it right
finally, make it fast

 

[T201016]

Remember the three stages of computer program optimisation:

first make it work
then make it right
finally, make it fast

The processor load in the so -called retirement:
5% ~ 11% | Temperature 40 ° C ~ 50 ° C | ± 4108 MHz ~ 4300 MHz | 1060 mV 12 Th Gen Intel (R) core (C) i7

Memory: 16 GB 3200 MHz | occupied 35%
Drive: SSD/EMMC1 500 GB

When the video files are converted:
CPU load 100% (SHL.Runsynchronous (-1))

I see here a partial misunderstanding of the subject.

I think that the disadvantage of my solution is the very use of video conversion
any external program, including ffmpeg.exe, with Shell support.
However, a computer with the above parameters should not be found
bigger problem with overloading the processor. The three points rule mentioned by the previous speaker
There is nothing to do with it. Yes, but only for the safe operation of the application itself.

Use for video conversion 100 files not exceeding 600KB, where the resulting .mp4 files
have no more size than 800KB, it should not cause problems even with the above
equipment construction or incorrectly written code. Please, do not overdo it

Ps. For accuracy - I learned these basic rules mentioned by the previous speaker while working on Siemens computers in Assembler
with a operational memory slightly more than 60 MB.
It was with such equipment that you had to really "gymnast"

 

[Magma]

@T201016 You can limit ffmpeg.. but this mean at the end your app job will be slower... but cpu will not used in 100%
For example if have 4 threads - use two (ffmpeg args):

-threads 2

This will give priority to your app - if you are doing the same time something different... pehaps showing the file size or a progress bar... and ofcourse the cpu will be cooler

edit: you can limit also cores... using (example):

cmd.exe /c start /affinity 3 "C:\Windows\System32\mspaint.exe"

this means will use CPU0 and CPU1

more info about affinity: https://www.ninjaone.com/blog/how-to-start-a-program-with-specific-cpu-affinity/

 

[emexes]

operational memory slightly more than 60 MB

60 MB, or kilobytes?

60 megabytes is heaps.

60 kilobytes is getting a bit tight for some applications.

Whoever squeezed chess into the 1 kilobyte ZX80 is a magician.

 

[Magma]

60 MB, or kilobytes?

60 megabytes is heaps.

60 kilobytes is getting a bit tight for some applications.

Whoever squeezed chess into the 1 kilobyte ZX80 is a magician.

assembly demoscene

 

[T201016]

60 MB, czy kilobajty?

60 megabajtów to sterty.

W przypadku niektórych zastosowań 60 kilobajtów staje się nieco ciasne.

Ktokolwiek wcisnął szachy do 1 kilobajta ZX80, jest magikiem.

This is not a mistake, in fact 60 MB (megabytes), and I mentioned large industrial computers from Siemens.
Siemens 4004 had 1 MB of operating memory and 3 x 55 MB of mass storage. And how was it used for the whole country?

 

[T201016]

@T201016 You can limit ffmpeg.. but this mean at the end your app job will be slower... but cpu will not used in 100%
For example if have 4 threads - use two (ffmpeg args):

-threads 2

This will give priority to your app - if you are doing the same time something different... pehaps showing the file size or a progress bar... and ofcourse the cpu will be cooler

edit: you can limit also cores... using (example):

cmd.exe /c start /affinity 3 "C:\Windows\System32\mspaint.exe"

this means will use CPU0 and CPU1

more info about affinity: https://www.ninjaone.com/blog/how-to-start-a-program-with-specific-cpu-affinity/

Hi @Magma
Finally, I see constructive help. I am just reading in the FFMPEG documentation about what you gave me and I will try this option. Thanks.

 

[Magma]

Hi @Magma
Finally, I see constructive help. I am just reading in the FFMPEG documentation about what you gave me and I will try this option. Thanks.

I believe that B4X is like a big family, where sharing knowledge with each other is the natural way of doing things.