[mercury-users] Style, Newbie decision question, "What? No X?!", Microbenchmark

[Fergus Henderson]

On 19-Nov-2002, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
> Fergus Henderson <fjh at cs.mu.OZ.AU> asked:
> 
> 	What exactly is evil about Posix threads?
> 	
> Nothing, as long as you drive them from a high level language where
> the compiler can give you some help, as opposed to driving them from C.
> 
> If you are driving them from C, you had better be omniscient
> (so that you get the stack size right in your call to
> pthread_attr_setstacksize(), because there is literally NO way to
> get this information from the C compiler, and the size may depend not
> only on which C compiler you used but what options you passed it)
> and infallible (so that you don't forget to update the number when
> you change anything about the code or the way it is compiled).

This is a reasonable criticism.

However, this problem is not limited only to Posix threads.
Exactly the same problem applies to Mercury threads in the low-level
back-end, even in the variant that uses only non-preemptive scheduling
rather than Posix threads.

The only significant improvement is that thread stack overflow is trapped
(by a non-catchable runtime error) on systems that support mprotect(),
and you get a better error message.

> For a language like Mercury, where the compiler knows what is going on,
> one would hope for a runtime system where separate threads start out
> with small enough stacks that one can reasonably have thousands of them
> and yet can grow when needed so that reasonable processes just work.

Yes, that is what one would hope for.
Currently, however, that is not what you will get.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------