Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 .. 5022
— 502,152 events total
2020-11-02 20:20:10 → coot joins (~coot@37.30.52.148.nat.umts.dynamic.t-mobile.pl)
2020-11-02 20:20:17 <monochrom> That sounds like s/shine/roast/, merijn. :)
2020-11-02 20:20:20 <merijn> No clue what was being discussed, but per my usual heuristic it's a safe bet
2020-11-02 20:20:26 <bqv> lmao
2020-11-02 20:20:37 × tms_ quits (thomaav@cassarossa.samfundet.no) (Ping timeout: 264 seconds)
2020-11-02 20:20:45 <merijn> 'cause no one ever gets signals right
2020-11-02 20:20:53 tomsmeding dies from apprehension
2020-11-02 20:20:57 <monochrom> To be fair, on certain other topics, I'm the one to say "as usual, all of you were wrong"
2020-11-02 20:21:00 hackage foldl 1.4.10 - Composable, streaming, and efficient left folds https://hackage.haskell.org/package/foldl-1.4.10 (GabrielGonzalez)
2020-11-02 20:21:12 <merijn> as for the safety of -threaded and signals the answer is pretty simple.
2020-11-02 20:21:50 <merijn> While I haven't actually audited the signal handling code in GHC's RTS yet, I've concluded from discussions in #ghc that it's impossible to predictably and correctly handle posix signals in any runtime
2020-11-02 20:22:24 <monochrom> Is that just the worst case? Or is that also the average case.
2020-11-02 20:22:45 <tomsmeding> for that statement to be correct you'll have to define "any runtime" more precisely
2020-11-02 20:22:49 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 20:22:51 <merijn> monochrom: The average case it "it'll probably approximate what you intended"
2020-11-02 20:22:52 <bqv> oh
2020-11-02 20:22:55 <bqv> tomsmeding: wait, yes it is
2020-11-02 20:22:56 <tomsmeding> not saying that posix signals are a great design, but they _can_ work
2020-11-02 20:23:00 <bqv> because xwayland
2020-11-02 20:23:01 <merijn> tomsmeding: Either of the existing threaded/unthreaded runtimes
2020-11-02 20:23:13 <monochrom> I have accepted approximations.
2020-11-02 20:23:16 <tomsmeding> bqv: yes xwayland seems to inherit the same sigusr1 shenanigans from a quick web search
2020-11-02 20:23:24 <bqv> (also i checked source, as i suspected, my program is sending USR1, not recieving it
2020-11-02 20:23:27 <monochrom> (E.g., when I said "I no longer ask for great software")
2020-11-02 20:23:43 × ggole quits (~ggole@2001:8003:8119:7200:c42a:651c:d46:c888) (Quit: Leaving)
2020-11-02 20:23:45 <merijn> Basically, the threaded RTS *and* the "unthreaded" (confusingly) use multiple threads
2020-11-02 20:24:10 <monochrom> But there is also the angle that I am not using POSIX per se, I am using specifically Linux.
2020-11-02 20:24:13 <merijn> But do absolutely nothing to control which threads get signals, which means you have zero predictability of what gets interrupted when and what you can safely do in your handler
2020-11-02 20:25:05 <merijn> monochrom: linux has never made anything from posix *more* robust :p
2020-11-02 20:25:12 <bqv> ooh you bastard
2020-11-02 20:25:13 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-11-02 20:25:15 <tomsmeding> so the runtime needs to handle the signal internally, then raise an asynchronous haskell exception or something at the earliest opportunity _outside_ the actual signal handler, at which point the haskell-level signal handler can run
2020-11-02 20:25:19 <bqv> installing the USR1 handler fixed it
2020-11-02 20:25:22 <tomsmeding> I assume the ghc runtimes do that?
2020-11-02 20:25:27 <tomsmeding> bqv: yay!
2020-11-02 20:25:36 → olligobber joins (olligobber@gateway/vpn/privateinternetaccess/olligobber)
2020-11-02 20:25:46 <bqv> that's kinda frustrating because now i'm not entirely sure what's even happening here
2020-11-02 20:25:50 <bqv> but oh well, it's solved at least
2020-11-02 20:25:56 <merijn> tomsmeding: Essentially, what I've concluded from work a few years ago on signal handling in a multi-threaded runtime is that there's only one possible way you can get any kind of predictable behaviour
2020-11-02 20:26:46 <merijn> You mask all signals in every thread, then have a single dedicated thread blocking on sigwait() (or it's pthread equivalent) and then have that thread set up the relevant flags/whatever to run user code
2020-11-02 20:26:51 <merijn> Anything else is insanity
2020-11-02 20:27:02 → tms_ joins (thomaav@cassarossa.samfundet.no)
2020-11-02 20:27:10 <bqv> but wait, even in haskell?
2020-11-02 20:27:22 <merijn> bqv: In all languages
2020-11-02 20:27:31 <geekosaur67> signals happen at a level below haskell
2020-11-02 20:27:33 <bqv> won't the runtime behave vaguely predictably due to lightweight threads
2020-11-02 20:27:34 <tomsmeding> bqv: some process in your tree, say P, assigns a SIG_IGN handler for SIGUSR1, and has another child process that still has the terminating SIG_DFL on SIGUSR1; then P starts xwayland, which detects SIG_IGN, sends SIGUSR1 to its parent which flows down to the other child, which terminates, which wreaks havoc
2020-11-02 20:27:37 <tomsmeding> hypothesis
2020-11-02 20:27:43 <tomsmeding> completely unproven :D
2020-11-02 20:27:50 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 272 seconds)
2020-11-02 20:27:57 <merijn> bqv: Yes, but those haskell threads are stilling running on pthreads at some point
2020-11-02 20:28:06 <merijn> s/stilling/still
2020-11-02 20:28:08 <christo> in haskell you can have 2 threads running simmultaneously right?
2020-11-02 20:28:09 <bqv> hmm
2020-11-02 20:28:16 <christo> or n threads
2020-11-02 20:28:16 <merijn> christo: Sure
2020-11-02 20:28:29 <christo> i might be make a version of tetris in haskell
2020-11-02 20:28:34 <bqv> i mean moot point because i am using forkOS
2020-11-02 20:28:37 <merijn> christo: GHC does N:M multi-threading, so your multiplex N haskell threads on top of M OS threads
2020-11-02 20:28:38 <bqv> and -threaded
2020-11-02 20:28:39 <christo> and do all the music running at the same time with euterpea
2020-11-02 20:28:43 <tomsmeding> so merijn while you have a point about unpredictability of signals, it was _not_ actually the problem here ;)
2020-11-02 20:28:44 <monochrom> merijn: I think every expert agrees on that strategy, yes.
2020-11-02 20:28:46 <merijn> bqv: forkOS doesn't spawn OS threads
2020-11-02 20:29:04 <merijn> bqv: forkOS just prevents your Haskell thread from migrating between OS threads
2020-11-02 20:29:13 <bqv> right, bound thread
2020-11-02 20:29:36 <bqv> but then given i have the bound thread running exclusively ffi code, i have at least 2 threads
2020-11-02 20:29:38 <christo> in js i use canvas to draw, in haskell is there an equivalant? thx merijn
2020-11-02 20:29:38 <bqv> right?
2020-11-02 20:29:49 <merijn> christo: gloss, maybe?
2020-11-02 20:30:17 <christo> and in terms of networking, are there api's for that in haskell?
2020-11-02 20:30:18 <monochrom> No, forkOS has to spawn a fresh OS thread. What you want to not-guarantee is that this doesn't mean Haskell code will run on that OS thread.
2020-11-02 20:30:21 <christo> gloss? i'll look into it
2020-11-02 20:30:22 <merijn> bqv: That depends, for example are the safe foreign imports or unsafe foreign imports
2020-11-02 20:30:34 <merijn> christo: the "network" package? :p
2020-11-02 20:30:42 <bqv> er, hard to say
2020-11-02 20:30:44 <merijn> christo: It's basically a thin wrapper over posix sockets
2020-11-02 20:30:46 <bqv> i'm using inline-c
2020-11-02 20:30:46 <monochrom> Still, in practice, Haskell code will run on that OS thread, even though this fact is not future-proof.
2020-11-02 20:31:02 <christo> so in theory i can make an online tetris in haskell ?
2020-11-02 20:31:09 <merijn> monochrom: No, forkOS explicitly does not spawn a fresh OS thread
2020-11-02 20:31:16 <christo> or tetris client
2020-11-02 20:31:22 <monochrom> Therefore, I find "forkOS doesn't spawn an OS thread" is at best academic scaremongering, at worst a downright lie.
2020-11-02 20:31:58 <merijn> monochrom: forkOS spawns a bound thread, it doesn't affect the number of OS threads in existence
2020-11-02 20:32:56 <monochrom> Then you wouldn't have enough number of OS threads for sufficiently many independent C calls.
2020-11-02 20:33:32 × Katarushisu quits (~Katarushi@cpc149712-finc20-2-0-cust535.4-2.cable.virginm.net) (Ping timeout: 272 seconds)
2020-11-02 20:33:47 <merijn> monochrom: What? How are those two things remotely related to each other?
2020-11-02 20:34:22 → dbmikus_ joins (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com)
2020-11-02 20:35:00 <monochrom> Do you mind taking a look at my answer already written up at http://www.vex.net/~trebla/haskell/ghc-conc-ffi.xhtml ? You can scroll down to the section "thread-local FFI calls"
2020-11-02 20:35:03 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 20:35:31 <geekosaur67> those are I/O manager threads, and it'll block waiting for one to become available if needed
2020-11-02 20:36:02 × dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 264 seconds)
2020-11-02 20:36:07 <geekosaur67> separate pool from forkIO / forkOS threads
2020-11-02 20:36:39 <bqv> strange. the signal handler definitely solves the issue, but when i change the handler to do "something", it doesn't do that thing (but still solves the issue)
2020-11-02 20:36:46 ^[_ is now known as ^[
2020-11-02 20:37:09 <c_wraith> as I understand it, the only guarantee forkOS makes is that all safe FFI calls it makes will be on the same OS thread. Nothing about having exclusive access to that OS thread.
2020-11-02 20:37:12 × ^[ quits (sid43445@gateway/web/irccloud.com/x-iztepeaguyumtzta) (Changing host)
2020-11-02 20:37:12 → ^[ joins (sid43445@ircpuzzles/2015/april-fools/sixth/zgrep)
2020-11-02 20:37:26 <merijn> c_wraith: That's what the GHC docs say, yes
2020-11-02 20:37:59 <c_wraith> does the RTS actually give a stronger guarantee at this time?
←Prev  Next→
Page 1 .. 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 .. 5022

All times are in UTC.