Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat (limited to 'runtime/org.eclipse.etrice.runtime.c/src/platforms')
-rw-r--r--runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etLogger.c6
-rw-r--r--runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etTimer.c8
2 files changed, 13 insertions, 1 deletions
diff --git a/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etLogger.c b/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etLogger.c
index f4f5b38f2..e730556e4 100644
--- a/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etLogger.c
+++ b/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etLogger.c
@@ -16,6 +16,12 @@
#include <stdarg.h>
+/*
+ * Error log messages are redirected to stdout to preserve the chronological order of the logs.
+ * Furthermore writing to stderr from threads other than the main thread sometimes causes segfaults.
+ * This seems to be related to the fact that stderr ist usually unbuffered whereas stdout is buffered.
+ * However, I could not comprehend the problem.
+ */
void etLogger_logError(const char* message){
fprintf(stdout, "ERROR: %s\n", message);
diff --git a/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etTimer.c b/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etTimer.c
index 09606b8b0..5865d9269 100644
--- a/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etTimer.c
+++ b/runtime/org.eclipse.etrice.runtime.c/src/platforms/MT_POSIX_GENERIC_GCC/etTimer.c
@@ -94,7 +94,13 @@ static void timerHandler(int sig, siginfo_t *si, void *uc) {
etTimer* timer = si->si_value.sival_ptr;
int sval = 0;
- /* Do not acquire the timer mutex in the handler! See signal-safety in linux manual. */
+ /*
+ * Do not acquire the timer mutex in the handler!
+ * See signal-safety in linux manual.
+ * Amongst other things, this can cause deadlocks
+ * when the thread that executes the signal handler already holds the lock
+ * and then tries to acquire it again in the signal handler.
+ */
timer->osTimerData.signaled = ET_TRUE;
sem_getvalue(&(timer_sema.osData), &sval);

Back to the top