Multithreading 2/N: PROXY_TO_PTHREAD option #5527
Conversation
|
Also pushed a commit which makes |
| return (void*)__call_main(args->argc, args->argv); | ||
| } | ||
|
|
||
| static volatile main_args _main_arguments; |
There was a problem hiding this comment.
lgtm. just curious why this is volatile.
There was a problem hiding this comment.
Agree that it is not needed here from compiler perspective. In general when I have shared state, if I don't use atomic operations to access the data and if there does not exist a mutex object associated with the shared data, I like to mark global data volatile more for documentation reasons ("see this thing here is shared between threads") (shared, not to mean synchronized for the pedantics). Here pthread_create is the synchronization primitive, rather than an atomic op or a mutex lock.
We don't really have a convention here in the codebase for this yet, could certainly go either way here. wdyt?
There was a problem hiding this comment.
Got it, sounds fine the current way.
…xy main() to be called in a web worker/pthread.
… Replace uses with -s PROXY_TO_PTHREAD=1 option.
The initial work to get
--proxy-to-workeroption to play nice with-s USE_PTHREADS=1was a dead end, because it led to having to do a call graph flow analysis of which compiled functions main thread might need, which became ridiculous. Instead, this PR implements another approach that ended up being successful.If -
s PROXY_TO_PTHREAD=1option is passed, then the applicationmain()function will be invoked in apthread_create()d function. There is nothing much magical here, since developers can also do this by themselves, but this has the big advantage of not needing to have Emscripten-specific boilerprate code aroundmain()to set up a worker context. Undoubtedly some users will want to avoid this and do their thread setups themselves, and there are still a lot of users who will want to continue to run the application main thread in the main browser thread, which is why we will have both options.