Emscripten gains experimental pthreads support
groups.google.com
groups.google.com
In my opinion, the pthread support itself works well now. But the biggest problem of the implementation is that SharedArrayBuffer, the pthread support calls for, is implemented only in Firefox currently.
One of the purpose to use emscripten is made an application cross-platform web application. You can get a "non-webbish" code runs only in Firefox with pthread-supported emscripten as of now.
I'm looking forward to other browsers with SharedArrayBuffer support, especially Mobile Safari.
But agree iOS Safari would be a great addition for this.
Then the 'idea' is only solving a small part of the problem.
Compatibility and wide distribution is as much a technological problem as threading - and a much harder one to solve.
It's wrong to belittle browsers for reinventing the easy parts of the problem when they are the best solution we've ever had to the hard part.
No it isn't because their solution isn't actually compatible with any other implementation than FF and will only eventually get in to next versions of browsers.
The whole problem is much more political (who invents it amd trough what process depends very much on what will be adopted as clearly shown in the past) than technical so I can understand OPs dislike of bad technical solutions for political reasons.
>It's wrong to belittle browsers for reinventing the easy parts of the problem when they are the best solution we've ever had to the hard part.
Arguable, with Windows 10 store and apps integration improvement (no need for full screen apps) I can see "desktop" moving to the similar sandbox model as phones, as far as I'm aware OSX also has app sand-boxing model.
I could see a .NET or JVM based cross platform solution that would require minimal changes for UI across platforms - Xamarin style but more polished/OSS. Creating cross platform wrappers for common functionality (eg. OpenGL, File System, etc.) is trivial and already done - no need to wait for standardization body and vendors to implement it by 2020.
That sounds like a good idea. Unfortunately, it's been tried multiple times by the biggest companies on the planet and has always failed.
Microsoft did try Silverlight but I feel like because it was a wrong approach (trying to integrate in to browsers instead of making it a cross platform app sandbox) that came from the wrong company at the time (no interest in actually providing a cross platform toolkit) it failed.
As someone who worked with Silverlight - I could see a Silverlight-like framework to work on WP/iOS/Android/Win10/OSX/Linux to deliver truly cross-platform application platform - it wasn't actually bad technically - and with the recent Microsoft CoreCLR open movement the entire stack would be OSS and even better than JVM based solutions (value types for eg. are pretty big for this kind of thing as you probably know as the entire thing is full of small point/vector/etc. data structures).
Again I feel like no company is in a position to make something truly cross platform except maybe new Microsoft with focus on cloud and enterprise IT.
Google wants you to stay in the browser, Apple wants to lock you to iDevices and OSX, Adobe needs to sell you stuff to make money. Mozilla needs it to be about Internet (that's both where their finances come from and what their org is about).
I mean, you're pretty much exactly describing Sun's failed playbook from the '90s here.
New JavaFX looked promising but it has it's own technical problems + it's developed by Oracle - I don't think I need to say more.
Right now I think most platforms support some form of sandboxed app model - all we need is a portable framework that can target all of them exposing a shared API but still allowing native access where needed with decent performance.
.NET/CoreCLR could be one such platform, JVM another.
C++/Qt tries to be this but honestly it's C++ - it's one of the few technologies where I'd say I'm more productive with HTML5 stack.
Rust/Servo could also deliver something similar down the road - maybe you could cut out a "fast" subset of CSS layout and DOM from servo (I'm guessing there are edge cases that make the rendering/layout hard/impossible to optimize) and have something that looks like web stack (could even be a strict subset) but is capable of doing 60 FPS GUI and at the same time can talk to the native code which can then use app/sandbox APIs.
Remember the thing that Microsoft was afraid of for the Web? A middle layer that makes your OS mostly irrelevant.
It took a roundabout way but we're getting there. Extremely high performance virtual machines that are all fairly compatible, are deployed across a vast range of operating systems and devices today.
Together with an UI toolkit that renders fairly similarly across all these devices.
Technically this maybe can't do things that a single computer couldn't do ages ago, but now every computer can run that code. And via LLVM you can compile almost anything to js.
And with a much better security model than "download random exe and run" as well.
The sneering merely shows that you haven't really thought about what is going on here.
And any computer can run just about any kind of code now. Ask someone to download Python or LuaJIT and they can run your code.
Security models? In Lua, you can empty the environment and start fresh. You have a perfect sandbox with the flip of a switch.
I don't think the grandparent comment is sneering. I think he has an opinion that disagrees with yours.
Enter Android+Lua: https://play.google.com/store/apps/details?id=com.nvreformat...
Not if it's compiled (C, C++ etc.), uses compiled libraries (many Lua, Java and .Net apps) or any system calls/libraries (.Net)