remi6397

> Well, it's not a separate process... WASM3 is just a WASM virtual machine... you can definitely still mess everything up with infinite loops... but this is an annoying problem...

On 1/2/22 02:37, Josh Goebel wrote: > > As a digression, WASM is sandboxed by design, so no need for > forking there. > > WASM is a specification -...

> Though perhaps you are talking/hinting about actual restrictions the OS itself can provide... like denying the process network access - even if it somehow "escaped the VM"... That's exactly...

> > we can still use threads where we can't fork(). > > I was referring to the possibility of neither. :-) Evidently you can fix such things with lightweight...

> > You cannot use fibers for that, as they are not preemptive. > > They don't have to be preemptive, you yield once in a blue moon inside loop...

> > , when you externally make one task yield to another task, > > IF your software yields in a timely fashion and doesn't have major bugs. Well, that's...

> We're talking about infinite loops in the users software - which the runtimes could catch and report without being preempted. How could the runtimes catch anything on the same...

> FYI: This isn't an argument against sandboxing other than to say "it's not needed to handle VM infinite loops well". That's a very big hammer for a tiny spinner...

> I don't really see that happening unless someone comes along whose interested in the coding, not just the discussing of it. I'm not sure how likely that is to...

By the way, the preview should actually be drawn *below* the primary UI, but that doesn't seem to be the case here, does it?