|
01:01
guifa joined
02:32
guifa left
05:46
JimmyZhuo joined
05:53
JimmyZhuo left
14:15
guifa joined
15:53
guifa left
|
|||
| timo | who wants to investigate if we can successfully fork under some circumstances where there are threads running by doing all sorts of terrible hacks? | 17:22 | |
| essentially, we have to shut down OS-level threads before we can fork, and then afterwards pick them back up so they can continue their work | |||
| if all we have is workers in a single ThreadPoolScheduler, and they are all just waiting for more work, and there is no such work, and the TPS could gain a method that you can call to get the threads to quit, then fork would be possible under these circumstances. it'd have to rebuild the workers (and supervisor thread) after the fork for stuff to continue working of course | 17:24 | ||
| lizmat | what would that gain us ? | 17:30 | |
| timo | i'm not yet sure when it would be a useful thing to have | 17:33 | |
| many server programs use "pre-forking" to do a bunch of init steps once, then have a "pristine" process that worker processes can be forked from, and these worker processes can then be cleaned up after a while or for whatever reason, which can do things like keep resource leaks in check when you can't be sure the work your workers are performing is fine, for example | 18:00 | ||
| you can of course fork before starting any threads, unless you do precompilation which involves subprocesses which causes threads to appear :) | 18:27 | ||
|
18:39
finanalyst joined
19:10
lizmat joined,
Geth joined
|
|||
| lizmat | timo: don't we always have threads due to spesh ? | 19:11 | |
| timo | spesh and the event loop thread are handled specifically by our fork implementation to stop before and restart after forking | 19:20 | |
| lizmat | ah, ok | ||
| timo | but if any user threads remain, it throws an exception | 19:21 | |
| lizmat | ok, so this could only work if all workers in TPS are being idle, right? | 19:22 | |
| so we would need a TPS.shutdown method, that would return with a Failure if not all workers are idle | |||
| timo | indeed. though what exactly happens to all the things scheduled for the future in the scheduler when they suddenly live on in two different processes is anyone's guess | 19:31 | |
| (based on what the end user actually has in their start and react blocks and what-not) | |||
| i was wondering the other day, while i was trying to fall asleep, that since MATCH is relatively high up in the profile for core setting compilation, whether we can be smarter about what we have to do by code-genning specific subs to be used by specific regexes | 19:54 | ||
| lizmat | well, one of the reasons MATCH is so high, is .subst handling | 19:57 | |
| which I started looking at raku.land/zef:lizmat/String::Utils#replace | 19:58 | ||
| which is about 8x as fast as the equivalent .subst | |||
| github.com/lizmat/String-Utils/blo...#L562-L571 | 19:59 | ||
| timo | what do we .subst while doing a core setting compile? | 20:00 | |
| lizmat | yeah, sorry... nothing as it's all nqp sorry | 21:25 | |
| m: role A { multi method gist(::?CLASS:D:) { 42 } }; class B does A { multi method gist(B:D:) { self.A::gist } }; say B.new | |||
| camelia | Cannot dispatch to method gist on A because it is not inherited or done by B in method gist at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| lizmat | this either needs to work, of have its error message altered ? | ||
|
21:54
finanalyst left
23:22
guifa joined
|
|||