export slaves

[bitemyapp]

Having a problem getting Snap and slave-thread to cooperate, we could potentially harvest the children if we had access to the MultiMap.

If you have an alternative or idea for making this work properly, that would be very much appreciated.

[nikita-volkov]

First of all, I would just hate to break the encapsulation by exposing the internals of the library.

I don't clearly understand your case. Have you tried running Snap from a forked slave-thread?

[bitemyapp]

@nikita-volkov I have tried what you suggest. Killing the tid spawned by slave-thread that is running (and blocking on) Snap's httpServe function doesn't kill the children spawned (also via slave-thread) in Snap's app init.

I know Snap is swallowing the ThreadKilled exception but I'm not yet sure if that's the problem.

Snap is using forkIO and forkOn to spawn the worker, does there need to be an unbroken chain of SlaveThread.fork in order for it to know the hierarchy of threads properly? Snap doesn't currently provide a way to use your own fork.

[nikita-volkov]

does there need to be an unbroken chain of SlaveThread.fork in order for it to know the hierarchy of threads properly?

Exactly. For "slave-thread" to work the way you expect, forkIO and friends shouldn't be used in intermediate threads.

The mechanics of thread-hierarchy are determined by the calling thread. Once you get an intermediate forkIO there, you get the dependency chain for the nested calls to the functions of "slave-thread" reset to top-level, since thus you get a link of that chain skipped.

I know Snap is swallowing the ThreadKilled exception but I'm not yet sure if that's the problem.

I doubt there is any issue with that particularly.

Killing the tid spawned by slave-thread that is running (and blocking on) Snap's httpServe function doesn't kill the children spawned (also via slave-thread) in Snap's app init.

Can you elaborate on that?

[bitemyapp]

Killing the tid spawned by slave-thread that is running (and blocking on) Snap's httpServe function doesn't kill the children spawned (also via slave-thread) in Snap's app init.

Can you elaborate on that?

Nothing novel here, it's the outcome of what you said is the case.

For "slave-thread" to work the way you expect, forkIO and friends shouldn't be used in intermediate threads.

That is, forking Snap's httpServe via SlaveThread and killing the ThreadId of that fork doesn't kill children further down the hierarchy because Snap has forkIO and forkOn in between the SlaveThread forks.

I don't yet know how to remedy this except for the framework to let us provide our own forking functions.

[nikita-volkov]

Nothing novel here, it's the outcome of what you said is the case.

What I mean is that I don't quite understand, which behaviour you expect. As much as I get it, it seems like everything behaves by design.

forking Snap's httpServe via SlaveThread and killing the ThreadId of that fork doesn't kill children further down the hierarchy because Snap has forkIO and forkOn in between the SlaveThread forks.

What I would expect from SlaveThread in such case is to deliver the ThreadKilled signal to Snap's top-level thread. Whatever Snap will do with that signal afterwards is up to Snap only. Hence it's either its issue or the behaviour, which its authors intended. So, unless SlaveThread does not deliver the signal, I see no issue of SlaveThread here.

[bitemyapp]

@nikita-volkov sorry, I don't think it's a problem with slave-thread's design and I don't mean to imply that it is. Rather, I was hoping for a solution that wasn't tantamount to "fork and vendor Snap so I can use SlaveThread.fork for the worker pool". I'll close this and stop bothering you now.