Subj : Re: which way is better, (JS_BeginRequest, JS_EndRequest) or (JS_SuspendRequest,
To   : netscape.public.mozilla.jseng
From : Brendan Eich
Date : Wed Sep 01 2004 07:49 pm

J.P. wrote:
> I was wonderring between following two methods, which onw is more 
> efficient?
> 
> //1. Keep calling JS_BeginRequest and JS_EndRequest repeatedly.
> non-JS-API calls
> JS_BeginRequest(ctx)
> JS-API calls
> JS_EndRequest(ctx)
> ...
> non-JS-API calls
> JS_BeginRequest(ctx)
> JS-API calls
> JS_EndRequest(ctx)
> non-JS-API calls

First, if there are no blocking i/o or thread/process ops, or 
long-running computations, in ..., you could do everything in one 
request.  If the entire contents of the request don't take too much 
wall-time (roughly order milliseconds, not seconds; depends on your app 
or server latency and throughput requirements too), then make requests 
as big as you can, given the known structure of your code's control flow 
and blocking/locking/lengthy operation graph.


> //2. Call JS_BeginRequest and JS_EndRequest once, and use
> //JS_SuspendRequest and JS_ResumeRequest in between.
> JS_BeginRequest(ctx)
> JS_SuspendRequest(ctx)
> non-JS-API calls
> JS_ResumeRequest(ctx)
> JS-API calls
> ...
> JS_SuspendRequest(ctx)
> non-JS-API calls
> JS_ResumeRequest(ctx)
> JS-API calls
> JS_SuspendRequest(ctx)
> non-JS-API calls
> JS_ResumeRequest(ctx)
> JS_EndRequest(ctx)


The reason to suspend and resume is to cope with nested requests, which 
can happen given code layering and reuse.  If you can prove that no 
outer request nests on ctx, then there is no reason to use suspend and 
resume (btw, you need a saveDepth variable to capture the return value 
of suspend, and to pass to resume).

/be

.