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

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.

Sebastian Wilhelmi
mailto:wilhelmi ira uka de

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]