Re: Removal of 'stack_size' and 'bound' from threads in GLib

[Soeren Sandmann <sandmann daimi au dk>]

Sebastian Wilhelmi <wilhelmi ira uka de> writes:

> > Sometimes the stack_size parameter is needed.  Even if it is
> > ignored on Linux without causing problems, other platforms may
> > have a default stack size that is too small.
> 
> But what can the application programmer do about it? If he says 'use
> 1 MB of stack', it might work on one platform, but fail on another,
> because the

If a program overflows the default stack on some platform, there may
be nothing to do, except ask for a larger stack, one that is large
enough to allow the program to run on any (known) platform.  Not
optimal, but The alternative would be to just not have the program
working on that platform.  

I think there should be some way to tweak the stack size, and calling
thr_create (..., stack_size, ...) oneself defies the purpose of the
thread abstraction.

> Granted, priority is not very portable, but at least it has an
> easily comprehensible meaning, which above all makes sense to care
> for, I think, whereas stack_size and bound are things, you would
> most likely not look at, unless forced to. In an ideal world they
> would just be set to the optimal value automatically.

You should not look at priority either, unless forced to.  If you need
to influence the scheduler in a nonportable way, you are in at least
as much trouble as if you have to change the stack size.  Linux
ignores the priority unless the scheduling algorithm is also changed,
which is something only the superuser can do and glib doesn't provide
any API for.

> The g_thread_create_full seems like a good idea. But I would really want to
> postpone adding it until the first one says, that he _can't_ do without.

The first one to say that would be someone who has an application that
crashes on a certain platform.  IMO, he should not have to wait for a
new release of GLib to get it running.

Søren