If your threading library creates light weight processes (e.g. via clone()
on Linux), then yes, you’ll see them. *Normally* with pthreads the
“process ID” is the same for all threads, as they belong to the same
“process”.
POSIX threads (which is what Linux will use) have specific rules about
signals, and given that, its incredibly unlikely that your use of signals
will be in any way affected by the library. In fact, libnanomsg *today*
creates threads (not very many), so this differs only in the number of
threads, not in the actual presence of them.
For your extant PHP code, you can definitely continue to use libnanomsg —
regardless of whether libnng exists or not. Ideally in the future, libnng
will exist, and will offer a compatibility layer for legacy applications
like yours.
On Mon, Dec 12, 2016 at 12:22 PM, Martin "eto" Misuth <et.code@xxxxxxxxx>
wrote:
Hello,
I am using nanomsg with php7. I also don't consider myself at level or
capability to comprehend advanced topics required for messing with
internals of
this great library.
All I did was that I took unmaintained nanomsg php module for php5, and
modified it work on php7. I know php is probably not very liked, point is
it
is the language I am stuck with, for various reasons, I don't want go into
here.
On Sun, 11 Dec 2016 18:47:02 -0800about
Achille Roussel <achille.roussel@xxxxxxxxx> wrote:
Hello Garrett,
I’m happy to see some effort going into making nanomsg a better product,
however as a language binding maintainer (nanomsgxx) I have concerns
the amount of work that would go into changing the public API of nanomsg.
Similarly, the way I am using this, is rather simplistic. My use case is
simple "stitching together" of various standalone "long running" scripts
(let's pretend these are daemons), that communicate between themselves
using few
nanomsg "links".
Number of "observed" nanomsg FDs per process is rather low in my setups,
and by
description of my environment you can guess perfromance is not my primary
concern. Instead I am relying on great work done by developers in area of
scalability semantics and reliablity, and I don't have to invent my own
"half
baked" solutions (which would be beyond my limits anyway).
Currently most of these "things" talk among themselves only locally, but I
picked this library because I want to have ability to "spread out" onto
another
machines (should the need for that ever arise) and code at C level level is
reasonably easy to grasp for simpleton like me.
All scripts have single eventloop at their core and are based either on
simplistic wrapper build on top poll() I wrote, or on top of php7-libev
module (when I have more "dynamic" requirements).
I guess if I want to continue to use this to my advantage, I'll have to
adapt.
As such I have few idiotic questions. From cursory look I think I am able
to
decipher new API somewhat.
But as all my "things" are based on single event loop and rely O_NONBLOCK
behaviour of FD readyness notification from OS, I would be really grateful
if
this worked same way as currently. I would like to avoid writing "magic
pipes"
parts myself (as in two interconnected FDs parts). You said you are still
going
to provide this interface in new version, so do I understand correctly,
that it
should all still mesh together relatively easily?
From what I ingested so far I believe so. Am I wrong?
What am I bit concerned with are threads - will this mean my scripts will
suddenly start showing nanomsg threads as subprocesses (on OSes where
threads
are implemented this way (Linux)) in process listings?
If so, will this require considerable changes in the way I am doing singal
handling? I know threads and signals pose problems, and don't mix really
well
together.
I am relying on signal handling to receive control "events" from
supervisors.
As long as this won't end up by supervisor sending signals to random
nanomsg
threads willy nilly, I belive I am okay right?
Is that the case?
Thanks for reply, or even no reply, heh, in advance.
eto
