Page 5 of 11

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 05, 2017 3:41 pm
by Ivan Denisov
If Coroutines.Task has no performance benefits, why it is better than simple Services.Action ?

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 05, 2017 4:25 pm
by Ivan Denisov
I got some inspiration and working on new version based on last and first Josef's versions :)

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 05, 2017 4:35 pm
by Josef Templ
Ivan Denisov wrote:If Coroutines.Task has no performance benefits, why it is better than simple Services.Action ?
because it is a coroutine.

The advantage and the very purpose of coroutines is that you don't need
to save any state when you suspend and later resume the coroutine.
In the case of a Task this is done by calling Sleep.
It should be noted that the state of the Task here is not in the
coroutine object but in the Run method.
For this simple example it is of course easy to transform it into an Action
by moving the state into the object but try this for something like the
SameFringe problem.

- Josef

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 05, 2017 8:45 pm
by Ivan Denisov
Josef, let's make small step back to your initial proposal.

I moved the realization to Host subsystem and try to adopt some changes from last version.

http://blackboxframework.org/unstable/i ... a1.836.zip

I removed Task pattern to make it simpler for the debugging now. Later we can add it back. Dmitry also mentioned some efficiency troubles in the Community board.

Also I added ASSERT to Transfer to prevent using Transfer as GOTO. Also the Yield method can be generalized to Coroutine level.

However my version of code needs your attention. There is some segmentation fault because finalization goes wrong some place.
I afraid that can not find the reason soon. Can you please help to find the error!?

We can add HostCoroutines to HostDialog after this bug with Finalisation will be fixed later. Now build engine terminates build process because of this exit finalization troubles. (upd: That is why now HostCoroutines now imported only in ObxCoroutines).

I hope that my efforts will help to finish this issue and find some compromise solution which will be accepted by everybody.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Thu Apr 06, 2017 7:34 am
by Josef Templ
Ivan Denisov wrote:Josef, let's make small step back to your initial proposal.

I moved the realization to Host subsystem and try to adopt some changes from last version.

http://blackboxframework.org/unstable/i ... a1.836.zip

I removed Task pattern to make it simpler for the debugging now. Later we can add it back. Dmitry also mentioned some efficiency troubles in the Community board.

Also I added ASSERT to Transfer to prevent using Transfer as GOTO. Also the Yield method can be generalized to Coroutine level.

However my version of code needs your attention. There is some segmentation fault because finalization goes wrong some place.
I afraid that can not find the reason soon. Can you please help to find the error!?

We can add HostCoroutines to HostDialog after this bug with Finalisation will be fixed later. Now build engine terminates build process because of this exit finalization troubles. (upd: That is why now HostCoroutines now imported only in ObxCoroutines).

I hope that my efforts will help to finish this issue and find some compromise solution which will be accepted by everybody.
Ivan, you have destroyed a carefully implemented and tested implementation.
This is a very unfriendly action.
I am calling the chairman now.

- Josef

Re: issue-#156 adding Coroutines to BlackBox

Posted: Thu Apr 06, 2017 9:21 am
by Ivan Denisov
You version was not accepted by one of the author (Dmitry) and me because the realization (WinApi Fibers) was not separated. So I am working on the improvement. I will work on testing it and debugging if you can not help. There is no reason for panic, because with git we have all the history of versions, so all of your work is safe. But what is the cost of it if it can not be adopted without crunch?

I suggest to work in cooperation. I made work on splitting the realization how it should be done with any basic BlackBox interface, because you was not doing this by your self. Now I ask some help with correct finalization.

Yesterday I was very tired to finish this work, but was harry to share the results. In few days we can finish debugging.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Fri Apr 07, 2017 6:44 pm
by Josef Templ
Since I was not able to fix the bugs I had to reset this to a working version.
In addition some small improvements have been added:

Prime number calculation is now used as example for a background task.
Task.Sleep(0) has been optimized.
A task using Sleep(0) runs as fast as possible but without blocking the user interface.
Robustness of trap handling after exhausting the stack space has been improved.
Coroutines.Init now traps if a coroutine cannot be created.
Otherwise it is hard to see where the problem comes from.

The latest build is in http://blackboxframework.org/unstable/i ... a1.838.zip.

Ivan, please understand that it is not the scope of this issue to reorganize the Kernel or
anything else in BlackBox. It is only about adding a little feature within the current design.
Since Kernel is already importing WinApi anyway, there is no point in introducing another
Host-module for that. This is a dogmatic approach that doesn't help us to proceed with this issue.
In addition, it creates more problems than it solves if you look at the details.
And one thing must be clear: Dmitry is not making this decision.

- Josef

Re: issue-#156 adding Coroutines to BlackBox

Posted: Fri Apr 07, 2017 7:05 pm
by Ivan Denisov
Dmitry gave some important comments you do not want to hear. With ability to make Transfer from not main coroutine to another not main coroutine you are inventing hidden GOTO semantics. That is not good and should be forbidden with a TRAP. Dmitry understands everything about coroutines because implemented them in real industry objects with several platforms and designed Co_ for BlackBox Linux and XDS versions.

Task pattern (without Scheduler) is a big question. Services.Actions can store the state in it's record and there is no need in coroutines for scheduling some background task. Can you explain that is the background task that you can not solve with simple Services.Action?

I am supporting BlackBox for several platforms and the Center activity is only one side of my community job. So I can see that it is important to move WinApi to Host for easier Kernel sync and to port this new feature to Linux version (using u_context like Dmitry did). I gave the recipe for this by the Hook pattern and abstract Impl interface record. My first attempt was not succeed, however the second (build 836) was working (you can try ObxCoroutines). My third attempt maybe will work at glance.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Sat Apr 08, 2017 5:04 am
by Ivan Denisov
Let's go step by step.

I added ASSERT(current = main, 21) to Transfer procedure and moved Yield method to basic coroutines tools.

These changes does not break any stability and ObxCoroutines works well.
https://redmine.blackboxframework.org/p ... d82221a0b9

http://blackboxframework.org/unstable/i ... a1.839.zip

Re: issue-#156 adding Coroutines to BlackBox

Posted: Mon Apr 10, 2017 7:28 am
by Ivan Denisov
I moved realization to HostCoroutines.
http://blackboxframework.org/unstable/i ... a1.840.zip

Now there is no sigfault. The error had been caused by cleanup of main Fiber after it was already converted to thread. ObxExamples works fine.