[WIP] Introducing libuv global lock on master

[anton-malakhov]

As title
Partially replaces #29606 (removing kp/partr specifics)

[StefanKarpinski]

Out of curiosity, why not just continue it there?

[anton-malakhov]

I rebased it against master and wanted to keep original branch name for kp/partr-based branch there. GitHub does not allow changing source branch in a PR. If I'd retarget that PR to master 1) I'd loose few partr-specific changes which I can just keep in that branch and 2) it would look like if I want to merge kp/partr :)

[StefanKarpinski]

GitHub does not allow changing source branch in a PR.

It does: click Edit and then choose a different base branch.

[anton-malakhov]

I know it allows to change base branch but I said it does not allow changing source branch.
Let me probably clarify. I created initial PR against kp/partr branch because we were in a rush of making it stable during our F2F and anticipated that we can enable more than one thread by the end of the week. So, I made these quick changes in order to prepare for it at least in the libuv part and assuming it will remain being under review after merge into kp/partr. However, as Kiran's PR keeps struggling with more and more issues with single thread and I started to get full-fledged reviews for what was supposed to be a quick hack to meet our deadlines, I've decided to separate it out from kp/partr and continue addressing reviews and getting real CI tests on master branch. Thus I need new source branch. So, here we are.

[StefanKarpinski]

Closes issue #14494.

[c42f]

It looks like @yuyichao already reviewed this (partially? fully?) over at #29606.

Is the plan still to merge this before merging the other more PARTR-specific work? If so, what's holding it up and would it benefit from another review?

[anton-malakhov]

He made good point on not using JL_LOCK_NOGC. However, it never worked for me the easy way, triggering some bug or a problem during bootstrap. I'll be glad if somebody will take over this patch since my work is no longer connected to supporting development of multi-threading in Julia-lang

[c42f]

Ah that's a real shame. I could possibly pick it up. No promises yet though, I'll have to see what's involved.

@vtjnash what's your take on the order this stuff should get merged?

[StefanKarpinski]

@vtjnash what's your take on the order this stuff should get merged?

In a recent compiler call we discussed this and his take was that this is completely independent of the other multithreading work. It can happen before or after—it just affects whether calling I/O from different Julia threads is safe or not, which is an issue now and would still be an issue after the other threading PRs are merged as well.

[JeffBezanson]

Rebased as #31437.