[m-rev.] for review: avoid MR_call_engine in thread.spawn

[Julien Fischer]

On Thu, 26 Apr 2007, Peter Wang wrote:

> Estimated hours taken: 10
> Branches: main
>
> Change the implementation of thread.spawn in low-level C grades.  Previously it
> called the thread goal (a closure) via an exported Mercury procedure.  The
> problem with that is the call counts as a C -> Mercury call, and so goes via
> MR_call_engine() which sets up a large stack frame on the Mercury engine's C
> stack that won't be deallocated until the thread terminates.
>
> This is unnecessary inefficient since we can call the thread goal directly
> instead of via MR_call_engine().  The thread goal won't be returning to a C
> foreign proc when it finishes, and we don't need MR_call_engine() reserving
> C stack space for Mercury execution as any Mercury engine that is about to
> execute the thread goal would have that reserved space already.
>
> library/thread.m:
> 	As above.
>
> tests/par_conj/Mmakefile:
> tests/par_conj/spawn_many.exp:
> tests/par_conj/spawn_many.m:
> 	Add test case.

That looks okay.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------