[Webkit-unassigned] [Bug 65399] StackBounds checker fails on custom stack implementations (typically in a coroutine setting)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65399





--- Comment #7 from Slava Akhmechet <coffeemug at gmail.com>  2011-08-01 11:03:53 PST ---
(In reply to comment #6)
> One problem with this approach is that it assumes a single stack is used per context, which is not the case for JSC -- a single JSC context can be used on multiple threads (just not concurrently), so setting the stack bounds for a "context" doesn't necessarily make sense.

Yes, the idea is that every time the host program calls into the interpreter from a different coroutine, it would have to make the JSSetStackBounds call first. The same would apply to different threads, except the host would have to ensure it does proper serialization. JSC context group seems like the most logical object to set the bounds on, I can't think of a better way.

> That aside, the new function should go into JSContextRefPrivate.h
Thanks, will do. The change isn't *too* specific to us - custom lightweight threading implementations are actually pretty common, but it's definitely not something most embedders do.

> It seems to me that a better solution would be for JSC to have a mechanism that checked the actual stack extent that it's executing on, rather than requiring developers that are using this technique to jump through hoops to get the correct behavior.

Unfortunately with custom stack implementations that's not possible (or at least I can't think of a way to do it). The stack could start and end at essentially any location. It's easy for JSC to check where it currently is on the stack, but impossible to know where it ends without the host telling it. Since the boundary can change with every call into the interpreter (due to a coroutine switch), JSC must be notified every time there is a coroutine switch. The only way to tell automatically is to set up a protocol where the host can put some magic value and then have JSC scan the stack for it (or, alternatively, have the host unmap a page just after the stack and have JSC catch the fault signal), but that still requires a protocol, in addition to signal trickery. I think that's much worse (and more complex) than a clean API call.

Thanks for all the feedback - I'll make the changes.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.