questions around embedding `libunit` in Julia about unit HOT 2 OPEN

Hi @pankgeorg

Hello! I'm playing around with unit, trying to hook it up to julia. Julia has a quite neat c interface which can load .so files and call into them. I'm planning to wrap the libunit in a Julia jll package and then make a wrapper that will control unit internally (please excuse my juniority 🤗)

Sounds interesting...

* [ ]  documentation around the thread model of unit
  
  * How many threads does unit use?

The router process seems to start up three threads.

Some of the application processes can be threaded if you specify the 'threads' setting.

  * Are the C library calls thread safe (can I call them from many different julia threads simultaneously, or do I need to do locking julia side)?

I'm going to they are generally thread safe, as they use thread local storage, but the best way to find out is to just try it!

* [ ]  `libunit.so`: I'm making this with this rule, but I'm not sure if I'm missing anything

build/lib/libunit.so: $(NXT_LIB_UNIT_OBJS) \
		build/share/pkgconfig/unit.pc \
		build/share/pkgconfig/unit-uninstalled.pc
	$(CC) -shared -o $@ $(NXT_LIB_UNIT_OBJS)

can this be streamlined somehow? Why is only a static library (.a) created as of now? Am I missing something? Is this "completely" standalone, or does it need additional files? Can this (.so) file be included in upcoming binary distributions?

From what I can gather it's basically down to libunit not being a stable a API. It may change and if we install a changed libunit.so it may randomly break peoples stuff.

from unit.

From what I can gather it's basically down to libunit not being a stable a API. It may change and if we install a changed libunit.so it may randomly break peoples stuff.

I can tolerate some ABI instability, especially if the semantic versioning is respected. We won't be installing anything system wide- we would rather be loading the .so from the Julia depot (where Julia stores local code and dependencies)

from unit.