Logs: liberachat/#xmonad
| 2022-06-17 06:53:40 | → | alternateved joins (~alternate@37.120.211.100) |
| 2022-06-17 06:59:33 | × | alternateved quits (~alternate@37.120.211.100) (Remote host closed the connection) |
| 2022-06-17 08:01:10 | × | benin quits (~benin@183.82.28.222) (Ping timeout: 240 seconds) |
| 2022-06-17 08:01:17 | → | benin0 joins (~benin@183.82.28.222) |
| 2022-06-17 08:09:35 | × | matijja quits (~matijja@193.77.181.201) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-06-17 08:09:50 | → | matijja joins (~matijja@193.77.181.201) |
| 2022-06-17 08:55:33 | <liskin> | geekosaur: I don't think we have modules which fork a *thread*, because xmonad isn't built with -threaded unless you build it yourself, which can't be relied upon |
| 2022-06-17 08:55:47 | <liskin> | geekosaur: we do have modules that fork a *process*, but that's okay |
| 2022-06-17 09:50:32 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 244 seconds) |
| 2022-06-17 10:04:56 | → | Ether17 joins (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 10:06:18 | <Ether17> | so i came across, this issue using the window Frills Deco. When using it scrolling with the mouse wheel on the deco casue the window enter a kind of floating mode. Is there a way to disable this? |
| 2022-06-17 10:07:26 | × | Ether17 quits (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 12:33:41 | → | Ether17 joins (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 12:35:23 | × | Ether17 quits (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 12:36:27 | <geekosaur> | liskin, the rts uses green threads without -threaded |
| 2022-06-17 12:37:05 | <geekosaur> | although the one case I thought used forkIO instead uses xfork, so I guess you're right about that |
| 2022-06-17 13:03:27 | <liskin> | green threads are useless when you're blocked in a XNextEvent FFI call |
| 2022-06-17 13:03:51 | <liskin> | so any code that wants to actually do something needs to fork process |
| 2022-06-17 13:04:05 | <liskin> | (it's a different story in xmobar though) |
| 2022-06-17 13:06:09 | → | alternateved joins (~alternate@staticline-31-183-144-54.toya.net.pl) |
| 2022-06-17 13:11:29 | <geekosaur[m]> | pretty sure that's only true of "unsafe" FFI calls, "safe" calls go through the IO manager (which is still threaded even in the "non-threaded" runtime) |
| 2022-06-17 13:13:49 | → | Ether17 joins (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 13:14:56 | × | Ether17 quits (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 13:17:16 | × | rieper quits (~riepernet@sxbeta1.geo.uni-leipzig.de) (Remote host closed the connection) |
| 2022-06-17 13:24:52 | <liskin> | wouldn't that break the boundedness of the main thread? |
| 2022-06-17 13:25:15 | <geekosaur> | bound threads have bound FFI threads |
| 2022-06-17 13:26:44 | <geekosaur> | it's fairly complex but if you think about it this is the only way things can reasonably work: any given thread has an associated FFI thread, which comes from a pool for forkIO threads or is dedicated for forkOS threads or the main thread |
| 2022-06-17 13:27:03 | → | Ether17 joins (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 13:27:04 | <geekosaur> | otherwise some other Haskell thread will be blocked |
| 2022-06-17 13:27:47 | <Ether17> | how silly of me i had "$ windowArrange" in "myLayoutHook" sorry.. |
| 2022-06-17 13:27:50 | <liskin> | yeah and I thought other Haskell threads being blocked is precisely what happens |
| 2022-06-17 13:28:08 | <liskin> | (I still think that, because why would there be all those forks in xmonad and ifdefs in xmobar) |
| 2022-06-17 13:28:50 | × | Ether17 quits (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 13:28:57 | <geekosaur> | xmonad forks because it manages processes :) and double forking is to not have to worry about zombies, it's an old technique |
| 2022-06-17 13:29:03 | → | Ether17 joins (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 13:29:45 | <geekosaur> | some of the reason you might come to a different conclusion is there are a lot of FFI calls that are incorrectly marked unsafe. notably in network |
| 2022-06-17 13:29:46 | <liskin> | yeah but if what you're saying is true, it could just use threads in many cases |
| 2022-06-17 13:31:30 | × | Ether17 quits (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 13:32:11 | <geekosaur> | I think in most cases inside xmonad, sjanssen was simply following standard unix procedure and not trying to get clever with threads etc. |
| 2022-06-17 13:36:22 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2022-06-17 15:08:42 | <liskin> | hm, so I just did strace -f -k xmonadpropread, which I compile without -threaded and which does nextEvent on the main bound thread, nextEvent being a "foreign import ccall safe", and it doesn't spawn a separate thread and the blocking poll calls it does are from X11/xcb, not from GHC RTS |
| 2022-06-17 15:09:06 | <liskin> | so I think I'm going to maintain the illusion I might be right for a little longer :-)) |
| 2022-06-17 15:09:36 | <geekosaur> | it shouldn't be spawning a new thread. the IO manager has iirc 4 threads in a pool |
| 2022-06-17 15:09:59 | <geekosaur> | even in the "non-threaded" runtime, which trips people up sometimes |
| 2022-06-17 15:10:30 | <liskin> | strace would tell me about any clone calls where those threads are being created, and it would also start prefixing every line of its output with a task id had there been more than one |
| 2022-06-17 15:11:30 | <liskin> | I'd also see those threads in "ps axm", or in /proc/1384190/task/… |
| 2022-06-17 15:11:48 | <liskin> | there really are no threads unless I forgot how linux/unix works |
| 2022-06-17 15:13:00 | <liskin> | (not doing this to prove you wrong or prove myself right, just wanted to make sure my brain's idea of how the world works matches reality) |
| 2022-06-17 15:16:59 | × | benin0 quits (~benin@183.82.28.222) (Remote host closed the connection) |
| 2022-06-17 15:17:18 | <geekosaur> | for one, I don't think clone is used any more since LinuxThreads died, it proved impossible to emulate POSIX threads properly that way |
| 2022-06-17 15:25:40 | <liskin> | clone(child_stack=0x7f973e051eb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTIDstrace: Process 1395254 attached |
| 2022-06-17 15:25:42 | <liskin> | , parent_tid=[1395254], tls=0x7f973e052640, child_tidptr=0x7f973e052910) = 1395254 |
| 2022-06-17 15:25:44 | <liskin> | [pid 1395254] set_robust_list(0x7f973e052920, 24 <unfinished ...> |
| 2022-06-17 15:25:47 | <liskin> | this is xmobar compiled with -threaded |
| 2022-06-17 15:26:36 | <liskin> | which other syscall did you think was used to create a thread on x86_64? |
| 2022-06-17 15:27:04 | <liskin> | (actually I'm surprised there's a fork syscall at all; I'm fairly sure glibc does fork via clone as well) |
| 2022-06-17 15:27:14 | <geekosaur> | mm, I thought pthread_create mapped to a new syscall. I recall their trying to make clone work for threads multiple times and failing |
| 2022-06-17 15:28:12 | <geekosaur> | LinuxThreads was a disaster |
| 2022-06-17 15:28:26 | <geekosaur> | (back around kernel 2.4) |
| 2022-06-17 15:28:41 | <liskin> | I remember there being a thing called linuxthreads but I was too young/stupid at the time to understand what that was about |
| 2022-06-17 15:30:43 | <geekosaur> | okay, seems like they decided to redo clone as the new-thread syscall and make it behave properly for that, which meant putting new-process back on fork |
| 2022-06-17 15:33:21 | <liskin> | clone is just a new-task syscall with a gazillion flags about what should be shared with the calling task |
| 2022-06-17 15:34:09 | <geekosaur> | that was the promise of LinuxThreads. it proved not that simple |
| 2022-06-17 15:34:43 | <geekosaur> | they put a *lot* of effort into trying to make that work |
| 2022-06-17 15:35:13 | <lyiriyah[m]> | btw, I've just gotten titles working by rewriting `getName` based on geekosaur's code |
| 2022-06-17 15:35:56 | <geekosaur> | mm, the code there should have done basically the same thing as what I gave you for ghci |
| 2022-06-17 15:36:09 | <liskin> | wikipedia says: "NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library). However, NPTL requires specialized kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and wake |
| 2022-06-17 15:36:11 | <liskin> | again. The primitive used for this is known as a futex. |
| 2022-06-17 15:36:13 | <liskin> | " |
| 2022-06-17 17:28:10 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-06-17 17:28:23 | → | werneta joins (~werneta@137.79.237.183) |
| 2022-06-17 17:34:38 | × | werneta quits (~werneta@137.79.237.183) (Ping timeout: 246 seconds) |
| 2022-06-17 17:36:38 | → | werneta joins (~werneta@137.79.231.39) |
| 2022-06-17 18:05:37 | × | redgloboli quits (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2022-06-17 18:07:46 | → | redgloboli joins (~redglobol@user/redgloboli) |
| 2022-06-17 18:35:32 | × | redgloboli quits (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2022-06-17 18:36:22 | → | redgloboli joins (~redglobol@user/redgloboli) |
| 2022-06-17 18:54:24 | → | dschrempf joins (~dominik@mobiledyn-62-240-134-11.mrsn.at) |
| 2022-06-17 19:12:42 | × | dschrempf quits (~dominik@mobiledyn-62-240-134-11.mrsn.at) (Quit: WeeChat 3.5) |
| 2022-06-17 19:23:43 | × | alternateved quits (~alternate@staticline-31-183-144-54.toya.net.pl) (Remote host closed the connection) |
| 2022-06-17 20:27:39 | → | kayvank joins (~user@52-119-115-185.PUBLIC.monkeybrains.net) |
| 2022-06-17 21:48:29 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 2022-06-17 21:49:46 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2022-06-17 21:52:50 | × | werneta quits (~werneta@137.79.231.39) (Ping timeout: 244 seconds) |
| 2022-06-17 21:55:01 | → | werneta joins (~werneta@137.79.237.183) |
| 2022-06-17 23:41:06 | → | kwer[m] joins (~kwermatri@2001:470:69fc:105::1:4da1) |
| 2022-06-17 23:50:28 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4588) |
| 2022-06-18 00:20:01 | × | kayvank quits (~user@52-119-115-185.PUBLIC.monkeybrains.net) (Remote host closed the connection) |
| 2022-06-18 00:21:38 | × | werneta quits (~werneta@137.79.237.183) (Ping timeout: 244 seconds) |
| 2022-06-18 00:23:35 | → | werneta joins (~werneta@137.79.231.39) |
| 2022-06-18 02:03:32 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 246 seconds) |
| 2022-06-18 02:08:12 | × | td_ quits (~td@muedsl-82-207-238-251.citykom.de) (Ping timeout: 260 seconds) |
| 2022-06-18 02:09:58 | → | td_ joins (~td@94.134.91.116) |
| 2022-06-18 02:12:55 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Read error: Connection reset by peer) |
| 2022-06-18 02:13:17 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2022-06-18 02:24:27 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2022-06-18 03:29:58 | → | nev_yn joins (~nyven@c-68-43-234-118.hsd1.mi.comcast.net) |
| 2022-06-18 03:30:06 | × | nevyn quits (~k.dockz@c-68-43-234-118.hsd1.mi.comcast.net) () |
| 2022-06-18 03:35:01 | × | nev_yn quits (~nyven@c-68-43-234-118.hsd1.mi.comcast.net) (Quit: Leaving) |
| 2022-06-18 03:36:07 | → | nevyn joins (~nyven@c-68-43-234-118.hsd1.mi.comcast.net) |
All times are in UTC.