endurox-java

libnstd.dylib[0x11866] <+54>:  movq   0x38(%r14), %r12
libnstd.dylib[0x1186a] <+58>:  leaq   0x8(%r14), %rsi
libnstd.dylib[0x1186e] <+62>:  callq  0x123c0                   ; emq_notify
libnstd.dylib[0x11873] <+67>:  cmpl   $-0x1, %eax <<<<<<<<<<<<< this is last point int stack trace
libnstd.dylib[0x11876] <+70>:  jne    0x118f0                   ; <+192>
libnstd.dylib[0x11878] <+72>:  callq  0x2e518                   ; symbol stub for: __error

So could it be broken stack at some point in the emq_notify ?

$ git diff
diff --git a/libnstd/sys_emqueue.c b/libnstd/sys_emqueue.c
index 209db22..20915e9 100644
--- a/libnstd/sys_emqueue.c
+++ b/libnstd/sys_emqueue.c
@@ -379,7 +379,7 @@ expublic int emq_getattr(mqd_t emqd, struct mq_attr *emqstat)
 }

 /**
- * Confiugre notification
+ * Configure notification
  * @param emqd
  * @param notification
  * @return 
diff --git a/libnstd/sys_poll.c b/libnstd/sys_poll.c
index 7ad91d2..69e8006 100644
--- a/libnstd/sys_poll.c
+++ b/libnstd/sys_poll.c
@@ -187,7 +187,22 @@ exprivate void *sigthread_enter(void *arg)
     return NULL;
 }

-
+/**
+ * TODO: This shall be empty. As pthread_create() is not safe from signal
+ * handler.
+ * And for osx we shall not use signals for queue event dispatching, but
+ * instead we shall use threads.
+ * Another nice way of this would be to use thread pool for performance reasons
+ * not? I.e. SIGEV_THREAD for emq shall use thread pool (with one thread) to
+ * dispatch events through.
+ * 
+ * And this particular function shall be set to empty...
+ * 
+ * While thread pool is not available in Enduro/X 7.0, thus as part of the
+ * maintenance, we could just start new thread.
+ * 
+ * @param sig
+ */
 exprivate void slipSigHandler (int sig)
 {
     pthread_t thread;
@@ -266,7 +281,7 @@ exprivate int signal_handle_event(void)
     MUTEX_UNLOCK_V(M_psets_lock);

 out:
-        return ret;
+    return ret;
 }

 /**
@@ -308,7 +323,7 @@ exprivate void * signal_process(void *arg)
 out:
     return NULL;
 }
-    
+
 /**
  * Install notifications for all Qs
  */

Probably change shall be done in 7.5, as thread pool is available there. And also other places of pthread_create is fixed.

The 7.0 version could go with spawning new thread from emq, with 7.5 we shall port the code to thread pool. - this will not work, as there needs to be initiated destination process, but thread we can spawn only in local process.

Thus to avoid thread spawning during the signal wait, we could just write to another pipe the notification to signal thread.

Seems the most proper way for emq would be not to use signals, but instead the emq would deliver msg via pipe to other process. As we are processing only one epoll set (thought api allow more) we could just open named pipe for each process and let the main process to poll on this named pipe, thus process events in main thread.

- Or for each emq queue we create a pipe.
- Thus when emq sends msg: we lock the queue, write data to memory, put msg in pipe...
- When reading msg from queue: lock the queue at the position where we are ready to read from memory, we also read 1 byte from the pipe.

Thus servers may run poll on emq, as it is done with linux epoll sub-system.
Also wit this NDRX_MSGMAX cannot be larger than PIPE_BUF if we send 1 byte notifications.