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

[Soeren Sandmann <sandmann daimi au dk>]

Sebastian Wilhelmi <wilhelmi ira uka de> writes:

> - '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.

> - 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).

> Yes I know, this could hurt us later, but I think leaving both parameters in
> is worse, as it bloats the API with mostly unused parameters, which aren't
> even portable at all.

They are portable, but the implementation on some platforms is 'ignore
it'.  I agree they are API bloat and mostly unused, though.

> 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).