Re: Removal of 'stack_size' and 'bound' from threads in GLib
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: Gtk Development List <gtk-devel-list gnome org>
- Subject: Re: Removal of 'stack_size' and 'bound' from threads in GLib
- Date: Fri, 18 May 2001 10:19:18 +0200
Hi Soeren,
> > > 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.
Ok, your points really makes sense, so I did the following:
I added g_thread_create_full, which is just, what g_thread_create was before
and I added:
#define g_thread_create(func, data, joinable, error) \
(g_thread_create_full (func, data, 0, joinable, FALSE, \
G_THREAD_PRIORITY_NORMAL, error))
Furthermore I stated clearly in the doc, that using stack_size, bound and
priority is kind of discouraged.
>From GThreadPool however all of stack_size, priority and bound disapeared.
Bye,
Sebastian
--
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]