ThinBasic multithreading, data exchange and multi-machine load

[xLeaves]

LzRPA's multitasking system is perfected as Redis' full suite of features is developed.

Now select the multi-threaded project in the Create Engineering interface.

You can create an application that contains task features.

9985

Tasks can be controlled, including starting tasks, suspending tasks, restoring suspended tasks, and terminating tasks.

9986

Because the task function is simulated using multiple processes, there is no need to worry about the release of resources. As the process disappears, all occupied resources are automatically released by the system.

But this also brings some shortcomings, such as the difficulty of exchanging data between multiple processes.

My solution is to use Redis, I compiled the Win32 version of Redis Server, and developed a set of HiRedis libraries available for ThinBasic.

When the main process starts, the Redis server will be created (random port). When the task starts, the port will be passed as a parameter to the task, and the task will connect to this port.

Whether it is the main process or the task process, a Redis object named G is created, and data is written and read to G to complete data exchange between multiple processes.

Another advantage introduced by Redis is that the application written by ThinBasic is capable of multi-machine deployment.

9987

[xLeaves]

The ability to use multitasking is as simple as this, with a lot of code behind it.

The first is the encapsulation in Boot.tbs, which changes the TBMain entry to the Main entry, along with some code, including the branch method into the main process and into the task.

A section of the code is intercepted like this:

9988

Of course, LzRPA is not entirely for multitasking. Multitasking is only part of many plans, so in this code, I did some processing, and only when the multitasking module was introduced will the multitasking related code be triggered.

The multitasking code is relatively simple:

9989

As you can see, the main thread is responsible for creating the Redis Server and making sure it runs correctly, otherwise it will continually retry, and I should add a timeout mechanism for it in the future.

At the entrance of the task, only the G object is created and connected to the Redis Server created by the main process.

LzRPA wants to be a smarter IDE, so you can focus on the workspace on the right, and the Redis and RedisServer extensions are referenced in the project.

When the test runs or generates an EXE file, LzRPA will copy all dependent files into the corresponding directory, of course, including the code they depend on.

So the resulting EXE file directory is like this, these are fully automatic, no need to manually copy and change files.

9990

Of course, although the developers only wrote a small amount of code, after LzRPA processing, many dependent code was added to ensure that these functions can run accurately.

[ErosOlmi]

xLeaves,

you are doing great jobs with great ideas and solutions over there.
Using redis to sync multiple single isolated process is a great idea ... one of those ideas that borderline with geniality

And thanks for sharing with all of us to be of stimulus to do better

Great!
Eros

[xLeaves]

xLeaves,

you are doing great jobs with great ideas and solutions over there.
Using redis to sync multiple single isolated process is a great idea ... one of those ideas that borderline with geniality

And thanks for sharing with all of us to be of stimulus to do better

Great!
Eros

Hi Eros:

There are still some room for improvement in this achievement, such as the task of planning tasks.

I put the latest version of LzRPA on GitHub.

In addition to the source code of the editor, other parts are visible, some code snippets that are used together.

I think LzRPA is officially announced here, at least the English version should be produced first, so that language is no longer a hindrance to technical communication.

I will continue to work and let this day come as soon as possible.