Add Mutex OS API

[IgorDeepakM]

This is an initial show case for creating an OS API for druntime. I've opted for creating a struct with associated methods with optional included OS data. Using explicit calls was chosen because order might be important and also so that it can be interleaved with druntime generic code. This also includes explicit initialization and deinitialization because order might be important here as well, even if it might not be that in this example.

You might notice a large awful version switch case in mutex.d and it is intentional. The plan is that the imported OS specific file shall in the future be automatically imported based on configuration. Basically an enum string would do it here. The file can be imported by a mixin.

mixin("import core.sys." ~ config.osSysDir ~ ".sync.osmutex");

In the future when we have sorted out the OS configuration method this can be changed.

Another thing you notice is that each OS is responsible for the implementation and should not go to the POSIX implementation directly. Mutex is a very simple primitive that happens to be the same for every POSIX like OS but that might not always be the case. Then it is up to the OS implementation to augment the POSIX implementation if necessary. Also this is order for the future mixin import mentioned above to work properly.

In every OS implementation you also see in the beginning of the file something like:

version (Windows):

This is because the makefile seems to visit all the files regardless of the OS target. This is totally unnecessary and hopefully the opend executable can be more selective and only compile files that are intended for the OS target. When this is done these can potentially be removed.

This basically my strategy in order to create a more distinctive interface to the OS. A programmer should by just looking at osmutex.d be able to figure out what is needed to adapt druntime for their own purpose. More of this to come, I will try to gradually implement APIs for each druntime functionality that interfaces the OS. In small steps so that the cognitive load is small.

[IgorDeepakM]

Why aren't the checks running. I thought we fixed that.

[adamdruppe]

I don't know it says waiting but the actions tab doesn't say it is doing anything at all.

[adamdruppe]

I think I got the action thing working, make sure you pull before anything else since i hit the github button to update from master to trigger it.

[adamdruppe]

copy/paste of what i put on the discord chat follows

as for the code in that pr.... im still a lil skeptical of two things:

1) that core.sys is the right place for this, since many of those are just bindings. on the other hand... it does seem to be a reasonable place to put it, especially since it is a kinda thin wrapper on top of said bindings... but it is something that must be compiled among a sea of things that often work without that

but.... since i don't have a better idea and some of the stuff in there needs a compilation pass anyway... just still i'd kinda prefer if the stuff that must be compiled in for druntime to work is more separate from just system external bindings that may or may not actually be used in any particular build

also core.sys is a public namespace and these might better be used internal

so... maybe rt.sys? or core.rt.sys or whatever the eexisting top level thign is called?

2) that the duplication for all the different things is worth it. but im kinda coming around to this because the public import to the generic one is actually pretty effective and the interface will be checked by trying to compile the top-level core.sync module. so as long as we compile that on the platform it ensures the interface works

so i think this is gonna be ok. keep the layering so ONLY the OS-specific minimal interface is in the core.rt.sys and the top level user interface stuff is in core and i think it might work. but just this is what i tried with simpledisplay and it ended up being a pain as things evolved later so.... im still a bit worried on a general note, the makefile listing all those files is kinda terrible. i wanna simplfy the crap out of that but there's both the makefile and the ldc-build-runtime and idk how much is duplicated between them

[adamdruppe]

Mac failed:

core/sync/mutex.d(241): Error: undefined identifier OsMutex, did you mean variable osMutex? core/thread/threadbase.d(80): Error: class Mutex is forward referenced core/thread/threadbase.d(81): Error: class Mutex is forward referenced

[IgorDeepakM]

so... maybe rt.sys? or core.rt.sys or whatever the eexisting top level thign is called?

Sure, just it can be moved to a separate folder. Just name where it is supposed to be moved.

It would actually be better to keep the os specific implementation separate so that the programmer can immediately see what files that needs to be changed.

[adamdruppe]

Yeah, I think rt.sys.* would be a good place to put it, then it is private to the runtime and along with other things in there etc.

[IgorDeepakM]

Mac failed:

core/sync/mutex.d(241): Error: undefined identifier OsMutex, did you mean variable osMutex? core/thread/threadbase.d(80): Error: class Mutex is forward referenced core/thread/threadbase.d(81): Error: class Mutex is forward referenced

I will be looking into it. I think this is because importing the OsMutes type fails. MacOS = Darwin right?

EDIT:

Do I need this thing because Darwin is not set by default?

version (OSX)
    version = Darwin;
else version (iOS)
    version = Darwin;
else version (TVOS)
    version = Darwin;
else version (WatchOS)
    version = Darwin;

[adamdruppe]

Yeah, Darwin is library-defined. So either gotta copy/paste that stupid spam into every module or factor it out to a static if enum or something.

[denizzzka]

Yeah, Darwin is library-defined. So either gotta copy/paste that stupid spam into every module or factor it out to a static if enum or something.

Maybe add Darwin to the compiler predefined versions?

[IgorDeepakM]

Yeah, Darwin is library-defined. So either gotta copy/paste that stupid spam into every module or factor it out to a static if enum or something.

Maybe add Darwin to the compiler predefined versions?

Yeah, that would help I think.