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

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Soeren,

> > - 'stack_size' is not portable. It is ignored in Linux and I think,
> > that the default stack size will meet most users need on all
> > platforms. Additionally it is platform dependent, how much stack will
> > be used by a given program, so it can't be calculated portably by the
> > programmer, so why bother using it.
> 
> 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
functions he is calling from the main thread function require unknown stacks
(Take printf for example). For example the solaris man page says:

It is usually very difficult to determine the runtime stack requirements for a
thread. PTHREAD_STACK_MIN specifies how much stack storage is required to
execute a NULL start_func. The total runtime requirements for stack storage
are dependent on the storage required to do runtime linking, the amount of
storage required by library runtimes (as printf()) that your thread calls.
Since these storage parameters are not known before the program runs, it is
best to use default stacks. 

Of course it also says:

If you know your runtime requirements or decide to use stacks that are 
larger than the default, then it makes sense to specify your own stacks.

But I consider stack_size unnecessary.

> > - Again 'bound' is ignored on Linux as every thread is bound. On
> > other platforms like Solaris a number of LWPs is automatically
> > allocated for all threads of a process, depending on how many threads
> > want to run concurrently. All in all it doesn't make sense to export
> > this property.
> 
> As I understand Solaris threads, they are user level threads that are
> scheduled on a number of LWP (light weight processed) that are kernel
> scheduled.  Does this mean that a Solaris thread can block a number of
> other threads if it blocks itself?  If so, the 'bound' property is
> useful.  (I don't think this is the case).

No, it is handled in the background and if you for example let 2 threads run 2
endless loops (busy waits), then both will get a LWP. But a LWP might be
shared among threads, which use much IO and the like. So the mapping threads
-> LWP might not be optimal at all times, but should work out all right.

> > If later there arises the urgent need for those parameters, I would
> > rather add functions g_thread_set_stack_size and g_thread_set_bound
> > functions, which will influence all subsequent thread creations
> > within the current thread.
> 
> What about g_thread_create_full() with the full api, and a
> g_thread_create() with the normally used parameters?  The small
> version of the function could perhaps lose 'joinable' and even
> 'priority' as well. (I don't think 'priority' is portable either).

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. 

On the other hand joinable of course is important, because that defines,
whether you want to join the thread later or not.

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.

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi