Re: [Fwd: Adding GThreadPool API to set per-thread stack size]

Hi Joe,

> The latest release of gnome-cups-manager exposed a problem with
> GThreadPools on FreeBSD.  Each thread in a thread pool can only have the
> default thread stack size.  On FreeBSD, this is 64 KB on most
> architectures.  As it turns out, this is not big enough to do CUPS
> operations within a thread, and thus gnome-cups-manager crashes with a
> stack overflow.

This indeed is unfortunate. On Linux you get some MB (maximum on i386 is
8 MB, can be limited by ulimit -s) virtual memory of stack for every
thread. Of course physical memory is only mapped, if it really is used.

The point with thread pools is, that the threads can be reused. That
however means that you have to use the standard values for stack size
and so on to avoid having to have pools for every parameter combination.

> I'm not sure what Linux uses as its default stack size (but I'd love
> someone to tell me).  However, I think it might be beneficial to add an
> API call to GThreadPool similar to g_thread_create_full().  This would
> allow per-thread stack size to be specified.  My idea would be to add:
> GThreadPool* g_thread_pool_new_full (GFunc func,
>                                      gpointer user_data,
>                                      gint max_threads,
>                                      gulong stack_size,
>                                      gboolean exclusive,
>                                      GError **error);
> This function would call g_thread_create_full() and pass the stack_size
> argument.  The only other solution I could think of is to use some
> arbitrary default stack size for all GThreads, but that seemed like too
> much of a hack.
> If I were to submit patches for this, would they be accepted?  Is this
> worth pursuing or does someone have a better idea?  Thanks.

> Since sending this the first time, I found that g_thread_pool_new() used
> to accept similar arguments to g_thread_create_full().  If adding a
> g_thread_pool_new_full() isn't an option, what about a configurable
> per-thread stack size in gthread-posix.c similar to the way the minimum
> stack size is set?

g_thread_pool_new has been changed to only take less arguments just to
make reusing threads possible. The only option I see right _now_ is to
not use thread pools for gnome-cups-manager, (which of course I wouldn't
like as the author of glib thread pools). In the long run a function

g_thread_pool_set_minimal_stack_size (size)

could be added to simply set the minimal stacksize for all threads in
the thread pool.

What about adding a bugzilla bug for that, such that it don't get lost.

Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |     är himmlen så förunderligt blå                    |

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