freenode/#clim - IRC Chatlog
Search
21:58:07
nyef
Why should stop-the-world GC require effort-to-stop proportional to the number of threads, rather than proportional to the number of CPU cores (thread execution engines)?
22:01:24
nyef
I know that it typically takes effort proportional to number of threads. But *why should it*?
22:01:42
oleo
don't you have to impend the effort on all threads rather than just some from the chores
22:05:13
nyef
Any thread not actively running is already stopped. Why go to the trouble of waking it up in order to put it back to sleep?
22:06:49
nyef
Or a thread that has exhausted its timeslice and the scheduler hasn't put it back on a CPU yet. It doesn't need to be stopped, it just needs to be prevented from restarting.
22:08:56
oleo
that would clog the pipeline of the scheduler, and you'd need a watchdog for each of'em
22:10:04
oleo
to prevent from restarting you have to always steal cpu from it, like in you have to watch over it
22:11:44
oleo
for one it would not be a problem but for many you'd at least need another thread/watcher....
22:13:08
oleo
and being external and having to count which ones you have to count over and bookkeeping, there is the original proces which spawned it all and has the history....you don't need that
4:21:18
beach
jackdaniel: I think I promised something I can't keep. I have lunch guests today, and I am going to be busy cooking pretty much all morning.
7:32:22
flip214
the first one should be useful, the other one is more a question about aesthetics -- I'd like to hear (or, rather, read ;) your opinion.
8:03:20
jackdaniel
alternative idea I'm thinking about is to provide appropriate around methods which queue operations in main clim thread if called from outside it
8:04:15
jackdaniel
regarding improving letf as a macro (i.e removing temporary variables) – if it is correct it sounds good to me (unless it blows some important case)
8:04:42
jackdaniel
to be honest letf macro looked too complicated to me so I didn't even try to refactor it :)
8:09:27
flip214
it replaces the lock across the whole section with 2 locking operations for the SETF durations only.
8:11:09
jackdaniel
(letf ((clip-region (smaller-region))) (do-something2) (do-something-else2)) ; in another thread
8:11:38
jackdaniel
if both smaller regions are different, then I can imagine situation, where we (do-something), (do-something2) (do-something-else) (do-something-else2)
8:12:12
jackdaniel
so the clip-region is incorrect in one of these cases (whichever setf was later), and may get incorrect if one of the threads finishes block earlier (which gets values back to "normal"
8:13:18
jackdaniel
it's not about concurrent write, but rather concurrent acceess in general (because we don't want to have this modified temporary state in another thread, we want "the legit one")
8:42:56
jackdaniel
as I said, if it is correct, then it is a clear improvement, and if it misses some important corner case it is not :)
8:45:26
jackdaniel
it looks fine tome from aesthetical point of view (but as I said, with-letf-lock is a rejected idea, so these parts ought to be removed)