future TODO main task scheduler for Windows

[FelixPetriconi]

Open issue:
future.hpp:1441
// TODO (sparent) : We need a main task scheduler for STLAB_TASK_SYSTEM_WINDOWS

[FelixPetriconi]

Can only be implemented for Windows 8 and 10

[FelixPetriconi]

Use the serial queue as a backup, if the OS not support one.

[zurrutik]

Hi,

At the moment I am replacing my own Concurrency library with stlab and I noticed that the main_executor is not implemented in neither Classic Win32 nor UWP( Windows 8/10 )

I haven't investigated the UWP case yet, but the Classic Win32 solution to the problem should be maybe something like this?
main_executor_changes.txt

wndProc.txt

Application::nativeWindowHandle() and Application::STLAB_EXECUTE_TASK should be provided by the application itself:

• nativeWindowHandle() should return the HWND of our main window( e.g. the value returned from Win32 CreateWindow() function )

• STLAB_EXECUTE_TASK should be the message id we want to assign( a safe value would be to use static constexpr int STLAB_EXECUTE_TASK = WM_USER + 0x0001; )

Do you think this can be implemented more elegantly? Any pointers?

Cheers

[FelixPetriconi]

I just changed to Windows 10, so I did not look into a solution so far.

I did an implementation for Qt some while ago. It is at the end of my ACCU 2018 slides: https://github.com/ACCUConf/ACCUConf_PDFs/blob/master/2018/Felix_Petriconi_-_There_Is_A_New_Future.pdf

As soon as I have time, I will add it.

[zurrutik]

Thanks for the info Felix!

[dabrahams]

@sean-parent I'm working on #412 but not sure how to address this one. Input?

[FelixPetriconi]

@sean-parent I'm working on #412 but not sure how to address this one. Input?

@dabrahams Since there are different main loops for different Windows tool sets, as far as I see it, it can be difficult to provide one that fits all. So far I have not seen a request for a main_executor. (I just work with Qt on Windows.)

[sean-parent]

I spent some time looking at this - I had always assumed Win32 had a main thread/window. But that does not appear to be the case. Instead, it seems closer to an actor model where every (root) window has its thread and message queue. The intent of the main_dispatcher wasn't to change the model of the underlying OS facilities but to provide a common way to interact with them. I think we need to rethink the main_executor idea. Perhaps instead we have a way to construct an executor from a platform resource. I would rather not provide a main_executor() where it doesn't make sense.

That said, MFC apps have a CWinApp which derives from CWinThread so a main-executor would make sense with the MFC framework.