Quirks with Node (and possibly other)

[aviramha]

while @meowjesty worked on #26 , we found out that in Node if you use the read"API (and not readfile) it actually forks to another process that does the open of the file and reading, and that forked process doesn't load our solution.
In order to make it work, there are two things that we need to solve:

1. Understand why the fork doesn't load our library, and fix that
2. Decide how we want to handle forks.

For fork handling there are two general ways to solve it as I see it:

1. Just run it as is - this would be a bit messy as it means each fork -> another agent and in applications written in JS that would slow down by a lot, causing an awful user experience.
2. First process is "parent" and any fork is "child". Parent deals with communicating to the agent, and children communicate through it (and can receive more elaborate state). It'd mean that each fork would be low cost and overall a better implementation.

Another question is whether we want to block the release of the files feature on this.

[aviramha]

I started investigating 1.
Node uses clone (probably some abstraction does it). When clone is called, init (by ctor) isn't called.
I tried re-calling the init function by hooking clone and then wrapping the target function of clone with our function that calls init again then calls the original function with original parameters.
This seems to work in a flaky way, 90% of the times it gets segfault and 10% it seems to work. My assumption is that the segfault happens because of some race condition with the function being passed to our callback, causing it to be invalid by the time we execute it.
The other approach I had in mind is to hook clone and set a hook on the target function.
I'll update the results soon.

[aviramha]

Okay this is quite embarrassing. the clone calls are for creating a new thread, not process. strace + Linux lingo makes it very hard to distinguish the two so that's why I was fixated on a fork happening.
What actually happened is that @meowjesty couldn't see where the seek is happening, and I didn't find any syscall that does open to the tested file. After running strace with -f we found out that another pid did it, but it's just another thread.
The reason we didn't see the seek is because of libuv calling the syscall directly instead of using libc, hence our hook not working. Solution would be to hook the uv function that wraps the syscall.

@eyalb181 I'd suggest doing it after first version of the file read being out, just to split the work. Up to you.