| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
This also includes a necessary API refactoring of crypto from IDENTITY
to UTIL.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This inserts a dedicated dummy marker task at the end of the ready queue at
the start of a pass. Because this marker task isn't visible to users of the
scheduler, it can't be canceled while the pass is being run. Additionally,
switching which ready queue is being run partway through by scheduling a
higher-priority task to immediately run also places this dummy marker. This
resolves both erroneous cases by which a pass can accidentally run an
unbounded number of tasks.
This also modifies GNUNET_SCHEDULER_get_load to not be misled by this extra
dummy task, and adds the now-passing test cases to the test suite.
Signed-off-by: Christian Grothoff <christian@grothoff.org>
|
|
|
|
| |
gnunet_private_config.h insanity
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows third party programs to use gnunet either with the
platform header from the sources used to build to gnunet, or use their
own platform header by defining GNUNET_CUSTOM_PLATFORM_H which will be
included in its stead.
This also means that programs no longer must include "platform.h" (or
similar) manually.
The change (should be) backwards compatible to some degree.
Fixes #4615
|
| |
|
|
|
|
| |
hogging the scheduler
|
| |
|
|
|
|
| |
With some other changes to sentences here and there as I found appropriate.
|
| |
|
| |
|
|
|
|
| |
work
|
| |
|
| |
|
|
|
|
| |
least 5
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
files.
configures and builds okay.
testsuite wasn't checked, will be checked.
diff including the plibc removal is now around 14370 lines of code less.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Without entering an asynchronous scope, logs are the same before. When
entering an asynchronous scope (either thread-based of
scheduler/task-based), all log lines within an asynchronous scope
contain its ID.
Currently this is only used in GNU Taler, for debugging requests across
multiple services. This allows us to get all log lines pertaining to a
particular request for a user or another service.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Christian Grothoff:
> I'm seeing some _very_ odd behavior with processes hanging on exit (?)
> with GNU libc 2.28-6 on Debian (amd64 threadripper). This seems to
> happen at random (for random tests, with very low frequency!) in the
> GNUnet (Git master) testsuite when a child process is about to exit.
It looks like you call exit from a signal handler, see
src/util/scheduler.c:
/**
* Signal handler called for signals that should cause us to shutdown.
*/
static void
sighandler_shutdown ()
{
static char c;
int old_errno = errno; /* backup errno */
if (getpid () != my_pid)
exit (1); /* we have fork'ed since the signal handler was created,
* ignore the signal, see https://gnunet.org/vfork discussion */
GNUNET_DISK_file_write (GNUNET_DISK_pipe_handle
(shutdown_pipe_handle, GNUNET_DISK_PIPE_END_WRITE),
&c, sizeof (c));
errno = old_errno;
}
In general, this results in undefined behavior because exit (unlike
_exit) is not an async-signal-safe function.
I suspect you either call the exit function while a fork is in progress,
or since you register this signal handler multiple times for different
signals:
sh->shc_int = GNUNET_SIGNAL_handler_install (SIGINT,
&sighandler_shutdown);
sh->shc_term = GNUNET_SIGNAL_handler_install (SIGTERM,
&sighandler_shutdown);
one call to exit might interrupt another call to exit if both signals
are delivered to the process.
The deadlock you see was introduced in commit
27761a1042daf01987e7d79636d0c41511c6df3c ("Refactor atfork handlers"),
first released in glibc 2.28. The fork deadlock will be gone (in the
single-threaded case) if Debian updates to the current
release/2.28/master branch because we backported commit
60f80624257ef84eacfd9b400bda1b5a5e8e7816 ("nptl: Avoid fork handler lock
for async-signal-safe fork [BZ #24161]") there.
But this will not help you. Even without the deadlock, I expect you
still experience some random corruption during exit, but it's going to
be difficult to spot.
Thanks,
Florian
|
| |
|
|
|
|
|
|
| |
wakeup
time
|
|
|
|
| |
Using the SCHEDULER_add* functions is now allowed before the first call to GNUNET_SCHEDULER_do_work.
|
| |
|
| |
|
| |
|
|
|
|
| |
1st shutdown did not finish the process
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
- GNUNET_SCHEDUELR_run_with_driver has been replaced with
GNUNET_SCHEDULER_driver_init and GNUNET_SCHEDUELR_driver_done
- GNUNET_SCHEDULER_run_from_driver has been renamed to
GNUNET_SCHEDULER_do_work (as it's no longer being called from a driver
callback)
- documentation has been updated
|
| |
|
|
|
|
|
|
|
| |
GNUNET_SCHEDULER_run_from_driver may now be called without any tasks
being ready if the timeout has not been reached yet. A warning is
printed because it may be a programming error in the driver (see
comments)
|
| |
|
|
|
|
| |
This reverts commit d45c008e677fa2fbff03e22745390d4775b031d2.
|
| |
|
|
|
|
| |
The reason field of tasks in the pending_timeout queue is never modified while the tasks are in the queue
|
|
|
|
| |
this shouldn't change anything but makes debugging easier.
|
| |
|
|
|
|
|
|
| |
- add assertions to make sure all tasks have been run or cancelled
- don't cancel all pending tasks during shutdown, only cancel the two
internal tasks scheduled in GNUNET_SCHEDULER_run_with_driver
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 5c4ae18d2e58c8bf3ba60a4f69251e304fbb9915.
|
| |
|