Monday, January 20, 2020

GWindow port status and what comes next of it (if mac wants to work)

GWindow port has been rough, fix a lot of the known issues ever since the old architecture on Linux platform. Some of the issues include race conditions because the window thread on Linux is launched as detached, so whenever the main thread finishes working, the window thread will still reference the memory that has already been cleaned up. Another issue is that X11 library doesn't have good documentation, at one point the window thread was deadlocking, preventing main thread from accessing any resource. That issue would've been fixed early on if X11 had better documentation on its API functionalities, but nonetheless with the asssistance of Alex, the bug has been squashed. Currently working on porting mac, because the new architecture hasn't been completely ported, so I have to also learn CMake and Objective-C to port GWindow on Mac. I also ported GDirectX11Surface, it was an straight forward porting because is in Windows OS. In summary: GWindow in new archietecture is fully operational on Windows and Linux OS, still working on Mac (I'm not sure if I'll be able to finish it to be honest) Afterwards I'll port GOpenGLSurface and update the executable for my tool (If I finish GWindow on Mac)


Here are some code snippets

This code is what caused race condition issue on Linux:

runLock = true;
linuxLoop = new std::thread(GWindowProcedure, std::ref(*this));
linxLoop->detach();

This is code that fixed the race condition:

runLock = true;
linuxLoop = new std::thread(GWindowProcedure, std::ref(*this));

~GWindowImplementation()
{
if (linuxLoop)
{
runLock = false;
linuxLoop->join();
delete linuxLoop;
linuxLoop = nullptr;
}
}

No comments:

Post a Comment