[webkit-dev] Feedback on enhancement proposal (custom stack bounds)

[Slava Akhmechet]

Hi All, I created a bug report for an enhancement proposal here:
https://bugs.webkit.org/show_bug.cgi?id=65399 I'm new to WebKit, and would
really appreciate guidance on how to improve the proposed solution. Here's
the bug report verbatim:


Much of the code in JavaScriptCore (specifically the parser), rely on
the StackBounds class to check that the interpreter doesn't blow the
stack in deeply recursive situations. StackBounds sets the m_origin
and m_bound member variables in its initialize() member in order to
define the stack limits and has custom implementations for different
platforms. We're embedding JavaScriptCore into our database project,
and the bounds checking breaks down for us for the following reason.
Our project is heavily event-driven, and instead of starting a thread
per client, we start a thread per CPU core, and multiplex multiple
coroutines within each thread. Our coroutine implementation manually
manages the stack pointer register, and allocates the stack space for
each coroutine on the heap. This is pretty common in event-driven
systems, and is typically achieved via getcontext/setcontext API on
POSIX platforms, and the Fibers API on Windows platforms. In order for
us to successfully integrate JavaScriptCore we need it to be able to
set custom stack bounds, as opposed to using the default
implementation provided by the StackBounds class.

I propose adding a function to the API that explicitly sets the stack
bounds for a given JSContext. It would be immensely useful for
projects that have custom stack implementations:

JS_EXPORT bool JSSetStackBounds(JSContextRef ctx, void *origin, void *bound);

This would set m_origin and m_bound members of the StackBounds class
for the given context. I am working on the patch now and would love to
see it committed to the tree, however I am new to WebKit and would
appreciate any guidance or suggestions for making this change (or
perhaps structuring it differently).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110729/0e63b804/attachment.html>