On 10/03/15 23:50, Martin Lucina wrote:
So, MySQL calls sigwait() in a loop from a signal handling thread. Standard
practice except that our sigwait is a stub, and thus mysqld wanders off
into busy-loop-land.

Any objections to something like the following to replace the
STUB(____sigtimedwait50)?

Wouldn't your patch result in the signal thread sleeping forever in the scenario you describe? I'm not saying it shouldn't, it just not what the patch immediately reads like in conjunction with your description.

First, _lwp_foo() should probably not be used outside of places where they are necessary. It's more of an internal interface, and let's keep uses of it to a minimum. That said, I can appreciate that we don't have an official way to suspend the execution of a thread indefinitely. Maybe it warrants an issue report? Something like "if (timeout) nanosleep else for (;;) sleep(100)" might be a better stepping stone, but no strong feelings about that.

Second, in general, should call the normal interface (_lwp_park) and not a versioned interface (___lwp_park60) unless there's a strong reason to do the latter.

diff --git a/platform/xen/lib/emul.c b/platform/xen/lib/emul.c
index 7b3fdc1..16313e5 100644
--- a/platform/xen/lib/emul.c
+++ b/platform/xen/lib/emul.c
@@ -14,7 +14,9 @@

  #include <errno.h>
  #include <fcntl.h>
+#include <signal.h>
  #include <stdlib.h>
+#include <time.h>
  #include <unistd.h>

  #include <mini-os/os.h> /* for PAGE_SIZE */
@@ -108,3 +110,13 @@ _exit(int eval)
         minios_stop_kernel();
         minios_do_halt(MINIOS_HALT_POWEROFF);
  }
+
+int ____sigtimedwait50(const sigset_t *set, siginfo_t *info,
+               const struct timespec *timeout)
+{
+       int rc;
+       rc = ___lwp_park60(CLOCK_MONOTONIC, 0, timeout, NULL, NULL, NULL);
+       if (rc == -1 && errno == ETIMEDOUT)
+               errno = EAGAIN;
+       return -1;
+}





Reply via email to