Peter Kasting wrote:
It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up.
So put it in the contract for the API you're designing on top of postMessage that you shouldn't call the method without some generous number of frames available. (Doesn't assuming you'll need to consume lots of stack frames work against your argument that postMessage receivers will usually do computation out-of-band anyway?) I don't see why this problem requires a technical solution rather than a social one. (I should have mentioned this in the first message, thanks for prompting me to bring it up now.)
And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned.
No, but *they* plan how they're going to use it, and they can adjust to not call with near-full stacks.
For this reason, I think talking about "the common case" misses the point -- a sync API is completely useless to anyone trying to write _any_ serious code defensively, large app or small, because it cannot be made safe except by using setTimeout to make it async, at which point synchronicity has bought you nothing.
"safe" is a misnomer. There's nothing security-related about this, except in the case that you write your code and create some inconsistency that a stack overflow leaves around which causes vulnerabilities (but really, you should have been careful about that already, e.g. what if the browser naturally runs out of memory at that point and stops your script? a malicious page could make this happen, with some effort). All that happens is an exception, and you can catch and deal with it in the rare case that it happens.
I prefer not to have APIs that force you to take action if you don't want to shoot yourself in the head.
Not catching an exception isn't shooting yourself in the head, it's just doing nothing; I think this is hyperbole.
If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too. I believe in pocket IE you have a ridiculously small stack depth [12?].
This surprises me, but realistically, no device is going to be able to afford to have such a low stack depth going forward anyway. Color me skeptical that mobile devices will have such small recursion limits in the foreseeable future. Moore makes many problems go away fairly quickly; I don't think we should penalize tomorrow for a limitation of today. Also, just because stack overflow is more common on mobile devices doesn't make stack overflow not a special case.
Given the number of websites relying on this feature right now (0?), how do you know what the special cases are?
Not "the" special case, "a" special case: stack overflow. I don't think a decent-sized percentage of web developers worry about stack overflow significantly more often than they worry about it from thinkos that accidentally cause infinite recursion. Jeff
