| 2022-06-17 00:48:46 +0200 | <liskin> | geekosaur[m]: the main thread is bound, and you can't fork a thread while staying inside of the X monad, and most people don't run xmonad with -threaded, so… |
| 2022-06-17 00:49:47 +0200 | <liskin> | but yeah with -threaded and manually forking a thread in IO and calling thread unsafe function that use global storage, things might go awry |
| 2022-06-17 00:50:22 +0200 | <liskin> | but then maybe the current Xlib uses thread-local storage? it certainly does use mutexes to protect its own shared data |
| 2022-06-17 00:52:58 +0200 | <geekosaur> | only if so enabled, which is a call I don't recall us making (and it slows X11 down a lot) |
| 2022-06-17 00:53:37 +0200 | <geekosaur> | but the real worry is internal state (that is, a static buffer). and we have modules which fork threads that open their own connections to the X server |
| 2022-06-17 00:54:14 +0200 | <geekosaur> | I don't offhand recall any of those calling directly or indirectly XGetTextProperty, but if any do there's one source of problems |
| 2022-06-17 00:54:33 +0200 | <geekosaur> | the other potential source is of course that presumably static buffer… and buffer overflows |
| 2022-06-17 00:54:58 +0200 | <geekosaur> | since there's no evident call to XFree anywhere, I have to assume it's static and therefore overflowable |
| 2022-06-17 00:55:42 +0200 | <geekosaur> | but I don't really want to dig into Xlib source to find out |
| 2022-06-17 01:01:22 +0200 | <geekosaur> | flip side, we've never heard of problems here before, so it either can't be too bad or is really hard to hit in most cases (but that leaves why lyiriyah[m] would be hitting it so consistently, which is some of what makes me wonder if `-threaded` might be involved) |
| 2022-06-17 01:03:56 +0200 | <liskin> | it's enabled by default since last xlib or two |
| 2022-06-17 01:04:03 +0200 | <geekosaur> | oh |
| 2022-06-17 01:04:20 +0200 | <geekosaur> | surprised I haven't heard any bitching about performance |
| 2022-06-17 01:14:13 +0200 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 246 seconds) |
| 2022-06-17 01:33:39 +0200 | <geekosaur> | oh wait,m they included their build script, and no `-threaded` |
| 2022-06-17 01:34:07 +0200 | <geekosaur> | sigh. I have no clue why `getName` would be taking the fallback path through `WM_CLASS` |
| 2022-06-17 01:37:42 +0200 | Guest67 | (~Guest67@2607:fea8:7ca0:2270:6044:2b47:5cac:b70f) (Quit: Client closed) |
| 2022-06-17 02:57:10 +0200 | werneta | (~werneta@137.79.230.15) (Ping timeout: 240 seconds) |
| 2022-06-17 02:59:16 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-06-17 03:08:30 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-06-17 03:08:46 +0200 | werneta | (~werneta@137.79.224.184) |
| 2022-06-17 04:03:16 +0200 | banc | (banc@gateway/vpn/airvpn/banc) (Ping timeout: 246 seconds) |
| 2022-06-17 04:05:01 +0200 | werneta | (~werneta@137.79.224.184) (Ping timeout: 246 seconds) |
| 2022-06-17 04:06:51 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-06-17 04:09:14 +0200 | td_ | (~td@muedsl-82-207-238-107.citykom.de) (Ping timeout: 246 seconds) |
| 2022-06-17 04:11:15 +0200 | td_ | (~td@muedsl-82-207-238-251.citykom.de) |
| 2022-06-17 04:22:54 +0200 | banc | (banc@gateway/vpn/airvpn/banc) |
| 2022-06-17 05:00:01 +0200 | haasn | (~nand@haasn.dev) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2022-06-17 05:01:22 +0200 | haasn | (~nand@haasn.dev) |
| 2022-06-17 06:41:20 +0200 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) |
| 2022-06-17 07:11:37 +0200 | benin | (~benin@183.82.28.222) |
| 2022-06-17 07:58:20 +0200 | briannag[m] | (~briannagm@2001:470:69fc:105::2:2f90) |
| 2022-06-17 08:06:29 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2022-06-17 08:06:29 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2022-06-17 08:06:32 +0200 | allbery_b | geekosaur |
| 2022-06-17 08:10:27 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::4588) (Ping timeout: 240 seconds) |
| 2022-06-17 08:16:41 +0200 | Hash | (~Hash@tunnel686959-pt.tunnel.tserv15.lax1.ipv6.he.net) (Quit: ZNC - https://znc.in) |
| 2022-06-17 08:27:51 +0200 | alternateved | (~alternate@37.120.211.100) |
| 2022-06-17 08:39:19 +0200 | Hash | (~Hash@tunnel686959-pt.tunnel.tserv15.lax1.ipv6.he.net) |
| 2022-06-17 08:52:44 +0200 | alternateved | (~alternate@37.120.211.100) (Remote host closed the connection) |
| 2022-06-17 08:53:40 +0200 | alternateved | (~alternate@37.120.211.100) |
| 2022-06-17 08:59:33 +0200 | alternateved | (~alternate@37.120.211.100) (Remote host closed the connection) |
| 2022-06-17 10:01:10 +0200 | benin | (~benin@183.82.28.222) (Ping timeout: 240 seconds) |
| 2022-06-17 10:01:17 +0200 | benin0 | (~benin@183.82.28.222) |
| 2022-06-17 10:09:35 +0200 | matijja | (~matijja@193.77.181.201) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-06-17 10:09:50 +0200 | matijja | (~matijja@193.77.181.201) |
| 2022-06-17 10:55:33 +0200 | <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 10:55:47 +0200 | <liskin> | geekosaur: we do have modules that fork a *process*, but that's okay |
| 2022-06-17 11:50:32 +0200 | banc | (banc@gateway/vpn/airvpn/banc) (Ping timeout: 244 seconds) |
| 2022-06-17 12:04:56 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 12:06:18 +0200 | <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 12:07:26 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 14:33:41 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 14:35:23 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 14:36:27 +0200 | <geekosaur> | liskin, the rts uses green threads without -threaded |
| 2022-06-17 14:37:05 +0200 | <geekosaur> | although the one case I thought used forkIO instead uses xfork, so I guess you're right about that |
| 2022-06-17 15:03:27 +0200 | <liskin> | green threads are useless when you're blocked in a XNextEvent FFI call |
| 2022-06-17 15:03:51 +0200 | <liskin> | so any code that wants to actually do something needs to fork process |
| 2022-06-17 15:04:05 +0200 | <liskin> | (it's a different story in xmobar though) |
| 2022-06-17 15:06:09 +0200 | alternateved | (~alternate@staticline-31-183-144-54.toya.net.pl) |
| 2022-06-17 15:11:29 +0200 | <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 15:13:49 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 15:14:56 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 15:17:16 +0200 | rieper | (~riepernet@sxbeta1.geo.uni-leipzig.de) (Remote host closed the connection) |
| 2022-06-17 15:24:52 +0200 | <liskin> | wouldn't that break the boundedness of the main thread? |
| 2022-06-17 15:25:15 +0200 | <geekosaur> | bound threads have bound FFI threads |
| 2022-06-17 15:26:44 +0200 | <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 15:27:03 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 15:27:04 +0200 | <geekosaur> | otherwise some other Haskell thread will be blocked |
| 2022-06-17 15:27:47 +0200 | <Ether17> | how silly of me i had "$ windowArrange" in "myLayoutHook" sorry.. |
| 2022-06-17 15:27:50 +0200 | <liskin> | yeah and I thought other Haskell threads being blocked is precisely what happens |
| 2022-06-17 15:28:08 +0200 | <liskin> | (I still think that, because why would there be all those forks in xmonad and ifdefs in xmobar) |
| 2022-06-17 15:28:50 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 15:28:57 +0200 | <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 15:29:03 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) |
| 2022-06-17 15:29:45 +0200 | <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 15:29:46 +0200 | <liskin> | yeah but if what you're saying is true, it could just use threads in many cases |
| 2022-06-17 15:31:30 +0200 | Ether17 | (~Ether17@2401:f40:100c:a5fe:1ac0:4dff:fe69:b9d5) (Client Quit) |
| 2022-06-17 15:32:11 +0200 | <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 15:36:22 +0200 | banc | (banc@gateway/vpn/airvpn/banc) |
| 2022-06-17 17:08:42 +0200 | <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 17:09:06 +0200 | <liskin> | so I think I'm going to maintain the illusion I might be right for a little longer :-)) |
| 2022-06-17 17:09:36 +0200 | <geekosaur> | it shouldn't be spawning a new thread. the IO manager has iirc 4 threads in a pool |
| 2022-06-17 17:09:59 +0200 | <geekosaur> | even in the "non-threaded" runtime, which trips people up sometimes |
| 2022-06-17 17:10:30 +0200 | <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 17:11:30 +0200 | <liskin> | I'd also see those threads in "ps axm", or in /proc/1384190/task/… |
| 2022-06-17 17:11:48 +0200 | <liskin> | there really are no threads unless I forgot how linux/unix works |
| 2022-06-17 17:13:00 +0200 | <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 17:16:59 +0200 | benin0 | (~benin@183.82.28.222) (Remote host closed the connection) |
| 2022-06-17 17:17:18 +0200 | <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 17:25:40 +0200 | <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 17:25:42 +0200 | <liskin> | , parent_tid=[1395254], tls=0x7f973e052640, child_tidptr=0x7f973e052910) = 1395254 |
| 2022-06-17 17:25:44 +0200 | <liskin> | [pid 1395254] set_robust_list(0x7f973e052920, 24 <unfinished ...> |
| 2022-06-17 17:25:47 +0200 | <liskin> | this is xmobar compiled with -threaded |
| 2022-06-17 17:26:36 +0200 | <liskin> | which other syscall did you think was used to create a thread on x86_64? |
| 2022-06-17 17:27:04 +0200 | <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 17:27:14 +0200 | <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 17:28:12 +0200 | <geekosaur> | LinuxThreads was a disaster |
| 2022-06-17 17:28:26 +0200 | <geekosaur> | (back around kernel 2.4) |
| 2022-06-17 17:28:41 +0200 | <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 17:30:43 +0200 | <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 17:33:21 +0200 | <liskin> | clone is just a new-task syscall with a gazillion flags about what should be shared with the calling task |
| 2022-06-17 17:34:09 +0200 | <geekosaur> | that was the promise of LinuxThreads. it proved not that simple |
| 2022-06-17 17:34:43 +0200 | <geekosaur> | they put a *lot* of effort into trying to make that work |
| 2022-06-17 17:35:13 +0200 | <lyiriyah[m]> | btw, I've just gotten titles working by rewriting `getName` based on geekosaur's code |
| 2022-06-17 17:35:56 +0200 | <geekosaur> | mm, the code there should have done basically the same thing as what I gave you for ghci |
| 2022-06-17 17:36:09 +0200 | <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 17:36:11 +0200 | <liskin> | again. The primitive used for this is known as a futex. |
| 2022-06-17 17:36:13 +0200 | <liskin> | " |
| 2022-06-17 19:28:10 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-06-17 19:28:23 +0200 | werneta | (~werneta@137.79.237.183) |
| 2022-06-17 19:34:38 +0200 | werneta | (~werneta@137.79.237.183) (Ping timeout: 246 seconds) |
| 2022-06-17 19:36:38 +0200 | werneta | (~werneta@137.79.231.39) |
| 2022-06-17 20:05:37 +0200 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2022-06-17 20:07:46 +0200 | redgloboli | (~redglobol@user/redgloboli) |
| 2022-06-17 20:35:32 +0200 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2022-06-17 20:36:22 +0200 | redgloboli | (~redglobol@user/redgloboli) |
| 2022-06-17 20:54:24 +0200 | dschrempf | (~dominik@mobiledyn-62-240-134-11.mrsn.at) |
| 2022-06-17 21:12:42 +0200 | dschrempf | (~dominik@mobiledyn-62-240-134-11.mrsn.at) (Quit: WeeChat 3.5) |
| 2022-06-17 21:23:43 +0200 | alternateved | (~alternate@staticline-31-183-144-54.toya.net.pl) (Remote host closed the connection) |
| 2022-06-17 22:27:39 +0200 | kayvank | (~user@52-119-115-185.PUBLIC.monkeybrains.net) |
| 2022-06-17 23:48:29 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 2022-06-17 23:49:46 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-06-17 23:52:50 +0200 | werneta | (~werneta@137.79.231.39) (Ping timeout: 244 seconds) |
| 2022-06-17 23:55:01 +0200 | werneta | (~werneta@137.79.237.183) |