Eh. How true. :( Care to step in?
It’s really simple. Take a sample application (for example 37_ParallelJoin), check what it’s doing and convert it into a unit test. [In this example, first button should cause a wait of about 3 sec and second button should cause a wait of about 5 sec. That’s all.] If the application you have chosen seems too complicated to be converted to a unit test, just ignore it and select another.
Why? Because I’ll be converting OmniThreadLibrary to support 64-bit and FireMonkey in the next week and I really could use a safety net which would ensure at least that I don’t break everything at once.
Why you? Because I’ll be converting OmniThreadLibrary to … but I already said that. If you can spend some time on that, then I don’t have to and everything will be finished quicker.
For really curious people – why 37_ParallelJoin? Because it is broken in the current SVN version. Parallel.Join.NumProc is not working correctly and I only noticed it by chance. [Fixing the bug right now …]
If you like OmniThreadLibrary but don’t feel competent enough to help developing it, this is your chance to step in and help the development effort!
"64-bit and FireMonkey?" Does OTL have anything in it that needs to be changed to specifically support FireMonkey?
ReplyDeleteWhen the information "flows" from the bacground thread to the main form, this is currently done with Windows messages. I have to change all code that uses messages to uses TThread.Queue - that will work in Windows and OS/X, on VCL and FMX.
ReplyDeleteThis is good news. Seems using TThread.Queue instead of using Windows messages makes perfect sense. If I didn't have to work 80+hrs/week for the rest of this year, I'd help.
ReplyDeleteHow do you thing that core functionality change from Windows messages to TThread.Queue will affect on performance etc?
ReplyDelete@Tommi, I looked at TThread.Queue implementation and I think the change will not be for worse.
ReplyDelete