Multithreading support?

[Kaned1as]

Hi. As I can see PRoot is now only single-threaded and looks at tracee signals sequentially one after another (event.c). Are there any plans on doing handler-per-tracee-thread implementation?

[jopasserat]

This is not part of the short-term plans. But feel free to document something over here if you have ideas to address this.

All the efforts are directed at solving #106 as far as I'm concerned.

Fancy joining?

[Kaned1as]

Thanks!

I've yet to understand codebase and implications of changes, but will post here in case of any ideas.

[jopasserat]

I've yet to understanding everything as well :)
But I'll try to format some notes that I've gathered here and there and make them available on the wiki so that everyone can contribute their bits too.

[vincenthage]

Hi Adonai,
I've found a mention of your idea at the end of the roadmap. Though implementing it reliably might take some time.

It might imply some issues with extensions/PRoot features that rely on having one unique central PRoot instance (like the netcoop and copy-on-write extensions, when they will be added).
But performance wise it might be worthwhile indeed.

[oxr463]

See also: #106 (comment)

[travarin]

Hi, is this still something you're interested in adding to the project? My partner and I from UT Austin would be interested in working on this for one of our classes.

[oxr463]

Yes please! Also, if you have any experience with seccomp, (See: #130).

I propose we implement libseccomp and multi-threading simultaneously, (See: seccomp/libseccomp#102).

[travarin]

Just to clarify, for libseccomp would we be implementing the tests under the TODO in #130?

[oxr463]

You mean these?

Create tests for seccomp:

• with PROOT_NO_SECCOMP
• without PROOT_NO_SECCOMP
• kernel version >= 4.8
• kernel version < 4.8

If so, the answer is yes; we need to be sure that PRoot will work properly regardless of kernel version or seccomp configuration.