procyberian/gimp
2
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-07-04 01:43:24 +00:00
Code Issues 1 Projects 1 Releases Packages Wiki Activity Actions
gimp/app/core/gimp-parallel.cc

554 lines
15 KiB
C++
Raw Normal View History

app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimp-parallel.c
* Copyright (C) 2018 Ell
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Change the license URL from http://www.gnu.org/licenses/ to https://
2018-07-11 23:27:07 +02:00
* along with this program. If not, see <https://www.gnu.org/licenses/>.
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
*/
#include "config.h"
#include <gio/gio.h>
#include <gegl.h>
app: lower thread priority of independent async operations In gimp_parallel_run_async(), lower the priority of threads executing independent async operations. Independent operations are generally potentially long-standing background tasks, which we don't want to bog down the rest of the program. This is currently only implemented on Linux and Windows.
2018-05-29 09:42:03 -04:00
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif
#ifdef G_OS_WIN32
#include <windows.h>
#endif
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
extern "C"
{
#include "core-types.h"
#include "config/gimpgeglconfig.h"
#include "gimp.h"
#include "gimp-parallel.h"
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
#include "gimpasync.h"
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
#include "gimpcancelable.h"
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
app: indentation fix in gimp-parallel.cc
2018-11-14 10:53:44 -05:00
#define GIMP_PARALLEL_MAX_THREADS 64
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
#define GIMP_PARALLEL_RUN_ASYNC_MAX_THREADS 1
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
typedef struct
{
app: rename GimpParallelRunAsyncFunc to GimpRunAsyncFunc ... and move it to core-type.h, in preparation for next commit.
2020-03-14 00:10:20 +02:00
GimpAsync *async;
gint priority;
GimpRunAsyncFunc func;
gpointer user_data;
GDestroyNotify user_data_destroy_func;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
} GimpParallelRunAsyncTask;
typedef struct
{
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
GThread *thread;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
gboolean quit;
GimpAsync *current_async;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
} GimpParallelRunAsyncThread;
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
/* local function prototypes */
app: more gimp-parallel fixes Fix indentation in gimp-parallel.{cc,h}. Remove unused typedefs in gimp-parallel.h. s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
2018-11-14 10:58:58 -05:00
static void gimp_parallel_notify_num_processors (GimpGeglConfig *config);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: more gimp-parallel fixes Fix indentation in gimp-parallel.{cc,h}. Remove unused typedefs in gimp-parallel.h. s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
2018-11-14 10:58:58 -05:00
static void gimp_parallel_set_n_threads (gint n_threads,
gboolean finish_tasks);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: more gimp-parallel fixes Fix indentation in gimp-parallel.{cc,h}. Remove unused typedefs in gimp-parallel.h. s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
2018-11-14 10:58:58 -05:00
static void gimp_parallel_run_async_set_n_threads (gint n_threads,
gboolean finish_tasks);
static gpointer gimp_parallel_run_async_thread_func (GimpParallelRunAsyncThread *thread);
static void gimp_parallel_run_async_enqueue_task (GimpParallelRunAsyncTask *task);
static GimpParallelRunAsyncTask * gimp_parallel_run_async_dequeue_task (void);
static gboolean gimp_parallel_run_async_execute_task (GimpParallelRunAsyncTask *task);
static void gimp_parallel_run_async_abort_task (GimpParallelRunAsyncTask *task);
static void gimp_parallel_run_async_cancel (GimpAsync *async);
app: in gimp-parallel, boost priority of waited-upon asyncs When an async that was created through gimp_parallel_run_async[_full](), and whose execution is still pending, is being waited-upon, maximize its priority so that it gets executed before all other pending asyncs. Note that we deliberately don't simply execute the async in the calling thread in this case, to allow timed-waits to fail (which is especially important for gimp_wait()).
2018-11-19 11:46:19 -05:00
static void gimp_parallel_run_async_waiting (GimpAsync *async);
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
/* local variables */
app: more gimp-parallel fixes Fix indentation in gimp-parallel.{cc,h}. Remove unused typedefs in gimp-parallel.h. s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
2018-11-14 10:58:58 -05:00
static gint gimp_parallel_run_async_n_threads = 0;
static GimpParallelRunAsyncThread gimp_parallel_run_async_threads[GIMP_PARALLEL_RUN_ASYNC_MAX_THREADS];
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
app: more gimp-parallel fixes Fix indentation in gimp-parallel.{cc,h}. Remove unused typedefs in gimp-parallel.h. s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
2018-11-14 10:58:58 -05:00
static GMutex gimp_parallel_run_async_mutex;
static GCond gimp_parallel_run_async_cond;
static GQueue gimp_parallel_run_async_queue = G_QUEUE_INIT;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
/* public functions */
void
gimp_parallel_init (Gimp *gimp)
{
GimpGeglConfig *config;
g_return_if_fail (GIMP_IS_GIMP (gimp));
config = GIMP_GEGL_CONFIG (gimp->config);
g_signal_connect (config, "notify::num-processors",
G_CALLBACK (gimp_parallel_notify_num_processors),
NULL);
gimp_parallel_notify_num_processors (config);
}
void
gimp_parallel_exit (Gimp *gimp)
{
g_return_if_fail (GIMP_IS_GIMP (gimp));
g_signal_handlers_disconnect_by_func (gimp->config,
(gpointer) gimp_parallel_notify_num_processors,
NULL);
/* stop all threads */
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
gimp_parallel_set_n_threads (0, /* finish_tasks = */ FALSE);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
}
GimpAsync *
app: rename GimpParallelRunAsyncFunc to GimpRunAsyncFunc ... and move it to core-type.h, in preparation for next commit.
2020-03-14 00:10:20 +02:00
gimp_parallel_run_async (GimpRunAsyncFunc func,
gpointer user_data)
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
{
return gimp_parallel_run_async_full (0, func, user_data, NULL);
}
GimpAsync *
app: rename GimpParallelRunAsyncFunc to GimpRunAsyncFunc ... and move it to core-type.h, in preparation for next commit.
2020-03-14 00:10:20 +02:00
gimp_parallel_run_async_full (gint priority,
GimpRunAsyncFunc func,
gpointer user_data,
GDestroyNotify user_data_destroy_func)
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
{
GimpAsync *async;
GimpParallelRunAsyncTask *task;
g_return_val_if_fail (func != NULL, NULL);
async = gimp_async_new ();
task = g_slice_new (GimpParallelRunAsyncTask);
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
task->async = GIMP_ASYNC (g_object_ref (async));
task->priority = priority;
task->func = func;
task->user_data = user_data;
task->user_data_destroy_func = user_data_destroy_func;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
if (gimp_parallel_run_async_n_threads > 0)
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
{
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
g_signal_connect_after (async, "cancel",
G_CALLBACK (gimp_parallel_run_async_cancel),
NULL);
app: in gimp-parallel, boost priority of waited-upon asyncs When an async that was created through gimp_parallel_run_async[_full](), and whose execution is still pending, is being waited-upon, maximize its priority so that it gets executed before all other pending asyncs. Note that we deliberately don't simply execute the async in the calling thread in this case, to allow timed-waits to fail (which is especially important for gimp_wait()).
2018-11-19 11:46:19 -05:00
g_signal_connect_after (async, "waiting",
G_CALLBACK (gimp_parallel_run_async_waiting),
NULL);
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
g_mutex_lock (&gimp_parallel_run_async_mutex);
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
gimp_parallel_run_async_enqueue_task (task);
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
g_cond_signal (&gimp_parallel_run_async_cond);
g_mutex_unlock (&gimp_parallel_run_async_mutex);
}
else
{
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
while (gimp_parallel_run_async_execute_task (task));
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
}
return async;
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
}
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
GimpAsync *
app: rename GimpParallelRunAsyncFunc to GimpRunAsyncFunc ... and move it to core-type.h, in preparation for next commit.
2020-03-14 00:10:20 +02:00
gimp_parallel_run_async_independent (GimpRunAsyncFunc func,
gpointer user_data)
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
{
return gimp_parallel_run_async_independent_full (0, func, user_data);
}
GimpAsync *
app: rename GimpParallelRunAsyncFunc to GimpRunAsyncFunc ... and move it to core-type.h, in preparation for next commit.
2020-03-14 00:10:20 +02:00
gimp_parallel_run_async_independent_full (gint priority,
GimpRunAsyncFunc func,
gpointer user_data)
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
{
GimpAsync *async;
GimpParallelRunAsyncTask *task;
GThread *thread;
g_return_val_if_fail (func != NULL, NULL);
async = gimp_async_new ();
task = g_slice_new0 (GimpParallelRunAsyncTask);
task->async = GIMP_ASYNC (g_object_ref (async));
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
task->priority = priority;
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
task->func = func;
task->user_data = user_data;
thread = g_thread_new (
"async-ind",
[] (gpointer data) -> gpointer
{
GimpParallelRunAsyncTask *task = (GimpParallelRunAsyncTask *) data;
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
/* adjust the thread's priority */
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
#if defined (G_OS_WIN32)
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
if (task->priority < 0)
{
Issue #3087: error compiling for Windows. s/THREAD_MODE_ABOVE_NORMAL/THREAD_PRIORITY_ABOVE_NORMAL/ Thanks to Sylvie Alexandre for noticing and searching this.
2019-03-08 17:29:16 +01:00
SetThreadPriority (GetCurrentThread (), THREAD_PRIORITY_ABOVE_NORMAL);
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
}
else if (task->priority > 0)
{
app: fix indepndent-async thread priority on Windows Positive and negative priorities got swapped...
2019-03-06 00:06:42 -05:00
SetThreadPriority (GetCurrentThread (), THREAD_MODE_BACKGROUND_BEGIN);
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
}
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
#elif defined (HAVE_UNISTD_H) && defined (__gnu_linux__)
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
if (task->priority)
{
app, meson.build: fix a bunch of warnings in C++ files
2019-09-12 19:51:04 +03:00
(nice (task->priority) != -1);
/* ^-- avoid "unused result" warning */
app: add gimp_parallel_run_async_independent_full() ... which is equivalent to gimp_parallel_run_async_independent(), except that it takes an additional "priority" parameter, which specifies the task's priority, with 0 being the default priority, and lower values indicating higher priority. Unlike gimp_parallel_run_async_full(), the priority parameter doesn't directly control the task's priority in a queue, but rather, we use it to control the priority of the task's dedicated thread, on supported platforms (previously, all independent async tasks would run with low priority.) Use low priority when loading fonts, which can take a long time, to keep the existing behavior.
2019-03-05 23:39:43 -05:00
}
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
#endif
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
while (gimp_parallel_run_async_execute_task (task));
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
return NULL;
},
task);
gimp_async_add_callback (async,
[] (GimpAsync *async,
gpointer thread)
{
g_thread_join ((GThread *) thread);
},
thread);
return async;
}
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
/* private functions */
static void
gimp_parallel_notify_num_processors (GimpGeglConfig *config)
{
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
gimp_parallel_set_n_threads (config->num_processors,
/* finish_tasks = */ TRUE);
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
}
static void
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
gimp_parallel_set_n_threads (gint n_threads,
gboolean finish_tasks)
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
{
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
gimp_parallel_run_async_set_n_threads (n_threads, finish_tasks);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
}
static void
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
gimp_parallel_run_async_set_n_threads (gint n_threads,
gboolean finish_tasks)
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
{
gint i;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
n_threads = CLAMP (n_threads, 0, GIMP_PARALLEL_RUN_ASYNC_MAX_THREADS);
if (n_threads > gimp_parallel_run_async_n_threads) /* need more threads */
{
for (i = gimp_parallel_run_async_n_threads; i < n_threads; i++)
{
GimpParallelRunAsyncThread *thread =
&gimp_parallel_run_async_threads[i];
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
thread->quit = FALSE;
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
thread->thread = g_thread_new (
"async",
(GThreadFunc) gimp_parallel_run_async_thread_func,
thread);
}
}
else if (n_threads < gimp_parallel_run_async_n_threads) /* need less threads */
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
{
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
g_mutex_lock (&gimp_parallel_run_async_mutex);
for (i = n_threads; i < gimp_parallel_run_async_n_threads; i++)
{
GimpParallelRunAsyncThread *thread =
&gimp_parallel_run_async_threads[i];
thread->quit = TRUE;
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
if (thread->current_async && ! finish_tasks)
gimp_cancelable_cancel (GIMP_CANCELABLE (thread->current_async));
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
}
g_cond_broadcast (&gimp_parallel_run_async_cond);
g_mutex_unlock (&gimp_parallel_run_async_mutex);
for (i = n_threads; i < gimp_parallel_run_async_n_threads; i++)
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
{
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
GimpParallelRunAsyncThread *thread =
&gimp_parallel_run_async_threads[i];
g_thread_join (thread->thread);
}
}
gimp_parallel_run_async_n_threads = n_threads;
app: flush async-operations queue when setting async thread count to 0 In gimp-parallel, always flush the async-operations queue (by executing all remaining operations on the caller thread) when setting the async-pool thread count to 0 (as happens when setting GEGL_THREADS=1, per the previous commit,) and not only when shutting GIMP down. Otherwise, pending asynchronous operations can "get lost" when setting GEGL_THREADS to 1. Additionally, in gimp_gegl_init(), initialize gimp-parallel before before connecting to GimpGeglConfig's "notify::num-processors" signal, so that the number of async threads is set *before* GEGL_THREADS, in order to avoid setting GEGL_THREADS to 1 while async operations are still executing. Also, allow setting the number of gimp-parallel-distribute threads while a gimp-parallel-distribute function is running (which can happen if gimp-parallel-distribute is used in an async operation, as is the case for histogram calculation), by waiting for the parallel-distribute function to finish before setting the number of threads.
2018-07-15 04:58:29 -04:00
if (n_threads == 0)
{
GimpParallelRunAsyncTask *task;
/* finish remaining tasks */
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
while ((task = gimp_parallel_run_async_dequeue_task ()))
app: flush async-operations queue when setting async thread count to 0 In gimp-parallel, always flush the async-operations queue (by executing all remaining operations on the caller thread) when setting the async-pool thread count to 0 (as happens when setting GEGL_THREADS=1, per the previous commit,) and not only when shutting GIMP down. Otherwise, pending asynchronous operations can "get lost" when setting GEGL_THREADS to 1. Additionally, in gimp_gegl_init(), initialize gimp-parallel before before connecting to GimpGeglConfig's "notify::num-processors" signal, so that the number of async threads is set *before* GEGL_THREADS, in order to avoid setting GEGL_THREADS to 1 while async operations are still executing. Also, allow setting the number of gimp-parallel-distribute threads while a gimp-parallel-distribute function is running (which can happen if gimp-parallel-distribute is used in an async operation, as is the case for histogram calculation), by waiting for the parallel-distribute function to finish before setting the number of threads.
2018-07-15 04:58:29 -04:00
{
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
if (finish_tasks)
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
while (gimp_parallel_run_async_execute_task (task));
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
else
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
gimp_parallel_run_async_abort_task (task);
app: flush async-operations queue when setting async thread count to 0 In gimp-parallel, always flush the async-operations queue (by executing all remaining operations on the caller thread) when setting the async-pool thread count to 0 (as happens when setting GEGL_THREADS=1, per the previous commit,) and not only when shutting GIMP down. Otherwise, pending asynchronous operations can "get lost" when setting GEGL_THREADS to 1. Additionally, in gimp_gegl_init(), initialize gimp-parallel before before connecting to GimpGeglConfig's "notify::num-processors" signal, so that the number of async threads is set *before* GEGL_THREADS, in order to avoid setting GEGL_THREADS to 1 while async operations are still executing. Also, allow setting the number of gimp-parallel-distribute threads while a gimp-parallel-distribute function is running (which can happen if gimp-parallel-distribute is used in an async operation, as is the case for histogram calculation), by waiting for the parallel-distribute function to finish before setting the number of threads.
2018-07-15 04:58:29 -04:00
}
}
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
}
app: in gimp-parallel, fix async-thread shutdown ... to prevent a potential deadlock.
2018-07-01 13:28:06 -04:00
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
static gpointer
gimp_parallel_run_async_thread_func (GimpParallelRunAsyncThread *thread)
{
g_mutex_lock (&gimp_parallel_run_async_mutex);
while (TRUE)
{
GimpParallelRunAsyncTask *task;
app: in gimp-parallel, fix async-thread shutdown ... to prevent a potential deadlock.
2018-07-01 13:28:06 -04:00
while (! thread->quit &&
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
(task = gimp_parallel_run_async_dequeue_task ()))
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
{
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
gboolean resume;
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
thread->current_async = GIMP_ASYNC (g_object_ref (task->async));
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
do
{
g_mutex_unlock (&gimp_parallel_run_async_mutex);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
resume = gimp_parallel_run_async_execute_task (task);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
g_mutex_lock (&gimp_parallel_run_async_mutex);
}
while (resume &&
(g_queue_is_empty (&gimp_parallel_run_async_queue) ||
task->priority <
((GimpParallelRunAsyncTask *)
g_queue_peek_head (
&gimp_parallel_run_async_queue))->priority));
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
g_clear_object (&thread->current_async);
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
if (resume)
gimp_parallel_run_async_enqueue_task (task);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
}
app: in gimp-parallel, fix async-thread shutdown ... to prevent a potential deadlock.
2018-07-01 13:28:06 -04:00
if (thread->quit)
break;
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
g_cond_wait (&gimp_parallel_run_async_cond,
&gimp_parallel_run_async_mutex);
}
g_mutex_unlock (&gimp_parallel_run_async_mutex);
return NULL;
}
static void
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
gimp_parallel_run_async_enqueue_task (GimpParallelRunAsyncTask *task)
{
GList *link;
GList *iter;
if (gimp_async_is_canceled (task->async))
{
gimp_parallel_run_async_abort_task (task);
return;
}
link = g_list_alloc ();
link->data = task;
g_object_set_data (G_OBJECT (task->async),
"gimp-parallel-run-async-link", link);
for (iter = g_queue_peek_tail_link (&gimp_parallel_run_async_queue);
iter;
iter = g_list_previous (iter))
{
GimpParallelRunAsyncTask *other_task =
(GimpParallelRunAsyncTask *) iter->data;
if (other_task->priority <= task->priority)
break;
}
if (iter)
{
link->prev = iter;
link->next = iter->next;
iter->next = link;
if (link->next)
link->next->prev = link;
else
gimp_parallel_run_async_queue.tail = link;
gimp_parallel_run_async_queue.length++;
}
else
{
g_queue_push_head_link (&gimp_parallel_run_async_queue, link);
}
}
static GimpParallelRunAsyncTask *
gimp_parallel_run_async_dequeue_task (void)
{
GimpParallelRunAsyncTask *task;
task = (GimpParallelRunAsyncTask *) g_queue_pop_head (
&gimp_parallel_run_async_queue);
if (task)
{
g_object_set_data (G_OBJECT (task->async),
"gimp-parallel-run-async-link", NULL);
}
return task;
}
static gboolean
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
gimp_parallel_run_async_execute_task (GimpParallelRunAsyncTask *task)
{
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
if (gimp_async_is_canceled (task->async))
{
gimp_parallel_run_async_abort_task (task);
return FALSE;
}
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
task->func (task->async, task->user_data);
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
if (gimp_async_is_stopped (task->async))
{
g_object_unref (task->async);
g_slice_free (GimpParallelRunAsyncTask, task);
return FALSE;
}
return TRUE;
}
static void
gimp_parallel_run_async_abort_task (GimpParallelRunAsyncTask *task)
{
if (task->user_data && task->user_data_destroy_func)
task->user_data_destroy_func (task->user_data);
gimp_async_abort (task->async);
app: add gimp_parallel_run_async() ... which runs a user-provided function asynchronously, returning a corresponding GimpAsync object. This can be used to execute code off the main thread, using the GimpAsync object to synchronize as necessary. Note that while the code allows for running multiple asynchronous functions in parallel in a thread pool, we currently limit the pool to a single thread, queueing overlapping async function, since we have no use for parallel asynchronous functions at the moment.
2018-05-11 11:43:06 -04:00
g_object_unref (task->async);
g_slice_free (GimpParallelRunAsyncTask, task);
}
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
static void
gimp_parallel_run_async_cancel (GimpAsync *async)
{
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
GList *link;
GimpParallelRunAsyncTask *task = NULL;
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
app: in gimp-parallel, cancel ongoing async operations upon exit When shutting-down gimp-parallel, cancel and/or abort any ongoing and queued async operations, instead of finishing them (async operations that already started executing will be canceled, but execution will be blocked until they're finished.) This is especially important since we're shutting down gimp-parallel before the destruction of data factories. This commit causes any ongoing async operations of the factories to be canceled on shutdown, rather than waiting for them to finish normally.
2018-10-01 05:13:45 -04:00
link = (GList *) g_object_get_data (G_OBJECT (async),
"gimp-parallel-run-async-link");
if (! link)
return;
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
g_mutex_lock (&gimp_parallel_run_async_mutex);
link = (GList *) g_object_get_data (G_OBJECT (async),
"gimp-parallel-run-async-link");
if (link)
{
app: fix gimp_parallel_run_async() cancelation In gimp_parallel_run_async(), when aborting a GimpAsync operation in reponse to its "cancel" signal, properly clean up internal data attached to the object, to avoid use-after-free if the signal is emitted again.
2018-05-27 13:53:02 -04:00
g_object_set_data (G_OBJECT (async),
"gimp-parallel-run-async-link", NULL);
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
task = (GimpParallelRunAsyncTask *) link->data;
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
g_queue_delete_link (&gimp_parallel_run_async_queue, link);
}
g_mutex_unlock (&gimp_parallel_run_async_mutex);
app: add gimp_parallel_run_async_{full,independent}() Remove the "independent" parameter of gimp_parallel_run_async(), and have the function always execute the passed callback in the shared async thread-pool. Add a new gimp_parallel_run_async_full() function, taking, in addition to a callback and a data pointer: - A priority value, controlling the priority of the callback in the async thread-pool queue. 0 is the default priority (used by gimp_parallel_run_async()), negative values have higher priority, and positive values have lower priority. - A destructor function for the data pointer. This function is called to free the user data in case the async operation is canceled before execution of the callback function begins, and the operation is dropped from the queue and aborted without executing the callback. Note that if the callback *is* executed, the destructor is *not* used -- it's the callback's responsibility to free/recycle the user data. Add a separate gimp_parallel_run_async_independent() function, taking the same parameters, and executing the passed callback in an independent thread, rather than the thread pool. This function doesn't take a priority value or a destructor (and there's no corresponding "_full()" variant that does), since they're pointless for independent threads. Adapt the rest of the code to the changes.
2018-07-01 09:57:46 -04:00
if (task)
app: allow progressive execution of parallel async operations In the gimp_parallel_run_async() family of functions, allow the async callback to return without completing the async operation, in which case the callback will be called again, until the operation is either completed, or canceled, in which case it is aborted (previously, returning from the callback without completing the operation would cause it to be aborted.) It is guaranteed that all operations of the same priority will get a chance to run, even if some of them contuinuosly return without completing. This allows potentially time-consuming operations to yield execution in favor of other same-priority operations, and, in particular, of higher-priority operations, to avoid priority inversion. Essentially, this allows a simple form of cooperative multitasking among async operations.
2018-10-09 12:38:41 -04:00
gimp_parallel_run_async_abort_task (task);
app: abort canceled pending operations in gimp_parallel_run_async() In gimp_parallel_run_async(), connect to the returned GimpAsync's "cancel" signal, and abort the operation in response if it's still enqueued, i.e., if its execution hasn't started yet.
2018-05-27 12:55:16 -04:00
}
app: in gimp-parallel, boost priority of waited-upon asyncs When an async that was created through gimp_parallel_run_async[_full](), and whose execution is still pending, is being waited-upon, maximize its priority so that it gets executed before all other pending asyncs. Note that we deliberately don't simply execute the async in the calling thread in this case, to allow timed-waits to fail (which is especially important for gimp_wait()).
2018-11-19 11:46:19 -05:00
static void
gimp_parallel_run_async_waiting (GimpAsync *async)
{
GList *link;
link = (GList *) g_object_get_data (G_OBJECT (async),
"gimp-parallel-run-async-link");
if (! link)
return;
g_mutex_lock (&gimp_parallel_run_async_mutex);
link = (GList *) g_object_get_data (G_OBJECT (async),
"gimp-parallel-run-async-link");
if (link)
{
GimpParallelRunAsyncTask *task = (GimpParallelRunAsyncTask *) link->data;
task->priority = G_MININT;
g_queue_unlink (&gimp_parallel_run_async_queue, link);
g_queue_push_head_link (&gimp_parallel_run_async_queue, link);
}
g_mutex_unlock (&gimp_parallel_run_async_mutex);
}
app: add gimp-parallel Add gimp-parallel.[cc,h], which provides a set of parallel algorithms. These currently include: - gimp_parallel_distribute(): Calls a callback function in parallel on multiple threads, passing it the current thread index, and the total number of threads. Allows specifying the maximal number of threads used. - gimp_parallel_distribute_range(): Splits a range of integers between multiple threads, passing the sub-range to a callback function. Allows specifying the minimal sub-range size. - gimp_parallel_distribute_area(): Splits a rectangular area between multiple threads, passing the sub-area to a callback function. Allows specifying the minimal sub-area. The callback function is passed using an appropriately-typed function pointer, and a user-data pointer. Additionally, when used in a C++ file, each of the above functions has an overloaded template version, taking the callback through a generic parameter, without a user-data pointer, which allows using function objects.
2018-04-04 15:16:42 -04:00
} /* extern "C" */
Reference in a new issue Copy permalink