About multithreaded applications...

[fvalasiad]

Let's say that i wanna compile the Linux kernel.

Obviously the way I'd probably go about it is:

./configure
make

In order for our program to work, the above script would be changed to:

./configure
build_recorder make

Now, the issue i wanna talk about is the case we run make with more than one hardware threads.

For example i know my computer's CPU is a two-core CPU with 4 hardware threads, so if i was to compile the Linux kernel I'd instead go at it like this:

./configure
make -j4

and equally, for build_recorder to work:

./configure
build_recorder make -j4

The above should work just fine, although i wanna stress out that it kills all purpose of using multiple threads. I am not entirely sure how wait(2) is implemented, but logging the order in which it picks stopped applications i noticed a pattern.

wait(&status) continuously yields the same process unless a new process is spawned or the process itself has exited

In other words, what would be a multi-threaded applications is transformed into a single threaded by build_recorder.

This happens because a previously stopped process, once restarted with ptrace(PTRACE_SYSCALL, ...) actually stops at another PTRACE_SYSCALL as instructed before our loop even reaches the next wait(&status), i suspect wait(&status) then just pops off the top of the waiting list and we end up with a bunch of threads on the waiting list.

This entire scenario really reminds me of the issues scheduling algorithms face with starving applications.

Proposal: We too should spawn a thread of tracer_main(3) every time a new process has spawned. How does this solve our issue? Well it simply transfers the process starvation problem to the kernel which is already perfectly capable of dealing with that sort of issue.

@zvr We are running out of time, this is probably the last sort of plan changes for this GSoC. We need to decide fast in order to implement it.

It's probably also simpler than what we are currently doing(trying to handle all the threads in a single thread).

Waiting for your thoughts on this!

[fvalasiad]

@zvr After the study at issue #144, we now have two options:

1. Create multiple threads of tracer_main(3)
2. Instead wrap expensive block of code inside of tracer_main's loop in separate threads.

In both scenarios we now have to deal with data races and thus for such a change we need to introduce pthread!

Unless you have a better idea of how to tackle this?