Support for unsupported platforms (by doing nothing)

[ichordev]

It would be really nice if there was a way to opt-in (via a version?) to using a fallback implementation on unsupported platforms. The fallback could just run each scheduled function sequentially, making it so that the library would transparently do nothing special on those platforms. This would make it much less of a headache to use this library in a cross-platform project.

[DmitryOlshansky]

I do not see how on unsupported platform I can do anything sensible, run everything in threads? Maybe but it's more work that is better spent actually supporting the platform in question.

[ichordev]

I do not see how on unsupported platform I can do anything sensible, run everything in threads?

Would it not be sensible enough to just run the scheduled functions in a foreach loop? That would work on any platform that the compiler supports.

Maybe but it's more work that is better spent actually supporting the platform in question.

I don’t think it’s that much work compared to supporting Android, OpenBSD, FreeBSD, NetBSD, DragonflyBSD, Solaris, Haiku, Xbox, PlayStation, and Nintendo Switch is it?

Optional dependencies suck, so can there please at least be some way to make it not static assert for an invalid platform so that I can write my own dummy implementation with the same API?

[DmitryOlshansky]

I don’t think it’s that much work compared to supporting Android, OpenBSD, FreeBSD, NetBSD, DragonflyBSD, Solaris, Haiku, Xbox, PlayStation, and Nintendo Switch is it?

Of these 4 systems are BSD and should be easily supported, Android is basically Linux so that is trivial, Solaris, Haiku etc. - somebody just makes a fork and tries to implement it.

I do not understand what good would it do to pretend that scheduling work only to have it block on some system call such as nanosleep. What's so nice about having it compile but breaking the core promises at run-time? I specifically added this static assert to make sure we properly support the system in question.

In my mind if you have an exotic system you just fork and add appropriate version'ed stuff. That's how you get workable solution not by pretending it somehow works. Also consider that properly implemented system should provide Events and Semaphores, that work across threads and fibers. I do not want to even imagine stopgap implementation of these.

[DmitryOlshansky]

Optional dependencies suck, so can there please at least be some way to make it not static assert for an invalid platform so that I can write my own dummy implementation with the same API?

That should be easy

version(SupportedOS) import photon;
else {
// define startloop, runFibers and go the way you like
}

[DmitryOlshansky]

Ah the problem is that by adding dependency you have it compile as dub package...

Let me think about it.

[DmitryOlshansky]

What if I provide a dummy implementation that simply assert(false) will that fly with what you intend to do?

Btw what's your target? Maybe we can just implement it properly?

[ichordev]

Ah the problem is that by adding dependency you have it compile as dub package...

Yep. Dub has 'optional dependencies', but there's no documentation on how to use them and they probably fetch & build the dependency anyway.

What if I provide a dummy implementation that simply assert(false) will that fly with what you intend to do?

It would be better if it was something like…

version(aaa){
	enum photonSupport = true;
}else version(bbb){
	enum photonSupport = true;
}else version(Photon_DummyUnsupported){
	enum photonSupport = false;
	//this version exports no symbols from Photon
}else{
	static assert(0, "UNSUPPORTED PLATFORM. To make Photon silently build nothing on unsupported platforms, use version `Photon_DummyUnsupported`");
}

So it's still abundantly clear that the platform is unsupported, but if you check for Photon support then you can implement the functions yourself without having to manually copy the version checks from Photon. And Photon wouldn't generate unnecessary code or export any conflicting symbols.

Btw what's your target? Maybe we can just implement it properly?

My goal is generally is to support everything. I listed above the platforms that I'm aware of and would therefore like to support.
My top priorities would be Android, then OpenBSD, NetBSD, and then the rest of the BSDs. Android is a Linux fork, so it might already work (is version(linux) is enabled on Android?), and the BSDs are all UNIX-like, and so should be fairly POSIX-compliant.