[osg-users] Building for platform without threads?

[OpenSceneGraph Users]

Hi all,

I’ve been working on an (improved) port of OSG to WebAssembly, and have a question for the experts :-) So far, my port runs well when built with threading support, but some browser implementations currently disable some of the threading support, so I need to have an alternative port which does not attempt to use threads at all.

What I’m curious about is how to configure the OpenThreads build (or whether it is advisable and/or possible to not involve OpenThreads at all) when building OSG. The WebAssembly compiler doesn’t hide the pthreads support in the headers when building single threaded, but doesn’t link against the pthreads library, so my current attempts to build single-threaded fail at link time.

I’ve looked through the OpenThreads CMakeLists, but it’s not obvious to me how to configure without any threading support at all.

Any advice?

Kind regards,
Phil
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[OpenSceneGraph Users]

Hi Phil,

OpenThreads is just written to support threads, there is no option for building without threads.  You'd need to add this yourself.

Cheers,

Robert.

[OpenSceneGraph Users]

OK, let me rephrase the question then. Is OpenThreads essential in OSG?

Kind regards,
Phil.

> On 27/03/2020, at 12:43 AM, OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:
>
> Hi Phil,
>
> OpenThreads is just written to support threads, there is no option for building without threads. You'd need to add this yourself.
>
> Cheers,
> Robert.

[OpenSceneGraph Users]

On Fri, 27 Mar 2020 at 05:50, OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:

OK, let me rephrase the question then. Is OpenThreads essential in OSG?

OpenThreads is used throughout the core OSG libraries.

If you want to build without threading then the way to do it would be to create a non op stub for the OpenThreads library.

Please remember what you are attempting to do is something that the OSG/OpenThreads was never envisaged to do, the fact that it might even possible is incredible, but it's so beyond what we ever wrote it for it's likely to provide a few hurdles.

 

 

[Chris Djali / AnyOldName3]

Hi Phil,

I believe you can build something with Emscripten's pthreads support enabled and then just avoid starting any threads if [i]emscripten_has_threading_support()[/i] returns false. The environments where pthreads don't work because shared memory isn't available will still load a library linked against pthreads and will behave nicely until you actually try spawning another thread. OSG can be run in single-threaded mode without you needing to reinvent the wheel.

Hope this helps,

Chris

[OpenSceneGraph Users]

Hi, Phil,

when you run single threaded osgViewer, you have single thread. Which
browsers don't like that and why?

Regards,
Michael.

[OpenSceneGraph Users]

The issue is actually before anything runs, it’s link-time errors (in this case, linking the compiled WebAssembly). OpenThreads uses the standard FindThreads.cmake module, which in the case of WebAssembly still finds the pthreads headers, but at link time no pthreads libraru is available so the pthreads symbols can’t be resolved.

I don’t recall if I mentioned earlier, but the multi-threaded version works just fine in multi-threaded WebAssembly. This depends on SharedArrayBuffer support in Javascript, which has been disabled in many browsers to mitigate spectre-style attacks. So I’m trying to support the single-threaded case as well to support those browsers. This is primarily on mobile platforms.

I guess to build a usable single-threaded version, what is needed is a patch to OpenThreads to ignore all pthreads headers, and effectively stub-out some of the methods. In single-threaded WebAssembly there are apparently still gcc-style internals available for atomics, so it wouldn’t be necessary to create new code for all stubs.

Kind regards,
Phil.

> On 30/03/2020, at 10:22 PM, OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:
>
> Hi, Phil,
>
> when you run single threaded osgViewer, you have single thread. Which
> browsers don't like that and why?
>
> Regards,
> Michael.

_______________________________________________

[Chris Djali / AnyOldName3]

Hi Phil,

As I said already, you should still be able to use a build that links against Emscripten's pthreads library in a browser that has no SharedArrayBuffer support provided you don't actually spawn any other threads. It should be as simple as calling emscripten_has_threading_support() and if it's false, calling osgViewer::ViewerBase::setThreadingModel(osgViewer::ViewerBase::SingleThreaded) on any viewers you create. In single-threaded mode, OSG does everything on the main thread, so you'll never actually call anything from Emscripten's pthreads library, never cause a SharedArrayBuffer to be created, and never upset the browser.

I hope this helps.

Chris

[OpenSceneGraph Users]

Hi, Phil,

I have a small sample with single threaded osgViewer that might help
you: https://github.com/OGStudio/openscenegraph-cross-platform-guide/tree/master/1.10.SampleWeb
OSG sources host the same Emscripten sample. Though, compile time
flags might need just a bit of tweaking (see
openscenegraph-cross-platform-guide open issues).

Regards,
Michael.