Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 .. 5022
— 502,152 events total
2020-11-02 20:38:17 <merijn> Possibly, according to monochrom
2020-11-02 20:39:33 <bqv> surely forkOS twice then has to spawn at least one thread (or reuse one), because the resultant bound threads can't be the same or you'd run into concurrency problems
2020-11-02 20:40:00 → ahmr88 joins (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net)
2020-11-02 20:40:01 <tomsmeding> unless there's already one laying around
2020-11-02 20:40:03 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 260 seconds)
2020-11-02 20:40:32 <bqv> exactly, yeah
2020-11-02 20:40:38 × domj quits (~domj@77.139.218.14) (Ping timeout: 260 seconds)
2020-11-02 20:40:45 <merijn> bqv: Why would you run into concurrency problems?
2020-11-02 20:41:11 <merijn> bqv: I don't see any conflict in having two bound threads on the same OS thread
2020-11-02 20:41:12 <geekosaur67> I don't think anything guarantees there won't be a block waiting for an available thread to run your FFI call on
2020-11-02 20:41:14 <bqv> merijn: envision a situation where both FFI threads block indefinitely
2020-11-02 20:41:19 <tomsmeding> bqv: the only reason I can think of that that happens (handler solves issue but doesn't run itself), is that some process between you and the SIGUSR1-sender detects that the SIGUSR1 handler is not SIG_DFL and therefore installs its own handler
2020-11-02 20:41:25 <merijn> bqv: Well, "don't do that, then" :)
2020-11-02 20:41:28 <bqv> lmao
2020-11-02 20:41:29 <tomsmeding> but that would be obscure
2020-11-02 20:41:30 hackage HDBC-postgresql 2.4.0.0 - PostgreSQL driver for HDBC https://hackage.haskell.org/package/HDBC-postgresql-2.4.0.0 (ErikHesselink)
2020-11-02 20:41:35 × AlterEgo- quits (~ladew@124-198-158-163.dynamic.caiway.nl) (Quit: Leaving)
2020-11-02 20:42:03 <merijn> bqv: Actually, that's already a problem if only one of them blocks indefinitely
2020-11-02 20:42:06 × sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2020-11-02 20:42:13 <bqv> tomsmeding: that sounds bizarre
2020-11-02 20:42:17 <monochrom> Huh? I thought the whole point of "safe FFI call" is it can block all it wants and no one else is held waiting.
2020-11-02 20:42:21 <merijn> bqv: If monochrom is right (which at casual glance of the code is probably true)
2020-11-02 20:42:24 <tomsmeding> bqv: I'm kind of hoping it's not true
2020-11-02 20:42:29 <merijn> bqv: Then that can't happen
2020-11-02 20:42:53 <merijn> monochrom: It looks like you are probably correct per the code, but that's not what GHC guarantees per the docs
2020-11-02 20:43:05 <monochrom> The docs are outdated.
2020-11-02 20:43:16 <merijn> Now, maybe the docs are wrong and don't provide strong enough guarantees
2020-11-02 20:43:44 <monochrom> There is even an old version of the doc that positive guaranteed you would have only one capability, ever.
2020-11-02 20:43:52 <monochrom> Now look at -N100.
2020-11-02 20:44:02 × refried_ quits (~textual@pool-108-20-26-90.bstnma.fios.verizon.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…)
2020-11-02 20:44:10 <merijn> monochrom: once you do a safe foreign call the capability is unlocked
2020-11-02 20:44:11 <bqv> signal() is a syscall, i can strace this...
2020-11-02 20:44:22 <merijn> So if you have another thread then safe foreign calls can never block Haskell code, sure
2020-11-02 20:44:25 <tomsmeding> bqv: watch for sigaction() instead I think
2020-11-02 20:44:47 <merijn> But I'm pretty sure that you can run out of safe call threads if you keep spamming enough blocking safe calls
2020-11-02 20:44:47 <tomsmeding> though things might detect being ptrace'd >:D
2020-11-02 20:45:21 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-11-02 20:45:29 <merijn> bqv: I hope to god that signal() isn't called
2020-11-02 20:45:52 <merijn> signal is broken and deprecated for two decades, it should be sigaction() as tomsmeding points out
2020-11-02 20:46:29 → u0_a298` joins (~user@47.206.148.226)
2020-11-02 20:46:43 → Katarushisu joins (~Katarushi@cpc149712-finc20-2-0-cust535.4-2.cable.virginm.net)
2020-11-02 20:46:51 → refried_ joins (~textual@pool-108-20-26-90.bstnma.fios.verizon.net)
2020-11-02 20:47:03 <bqv> i see a lot of rt_sigaction
2020-11-02 20:47:11 <bqv> none refer to usr1
2020-11-02 20:47:12 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 20:47:28 <tomsmeding> welcome to the world of strace, where you suddenly see the loads of crap that everything executes
2020-11-02 20:47:38 <bqv> in fact there's no reference to usr1 at all
2020-11-02 20:47:43 <bqv> unless it's numeric
2020-11-02 20:47:47 <monochrom> I like signal() when I'm just tell it to SIG_IGN or SIG_DFL. It's dreadful to have to fill out a form for just those. And I always have trouble deciding whether the other fields really matter or not for those cases.
2020-11-02 20:47:53 <bqv> 128?
2020-11-02 20:48:16 <tomsmeding> bqv: 10
2020-11-02 20:48:42 <tomsmeding> monochrom: glibc's surface signal(3) probably calls sigaction(2) under the hood
2020-11-02 20:48:42 <bqv> nothing for that either
2020-11-02 20:48:46 <bqv> bizarre
2020-11-02 20:48:53 <merijn> monochrom: Those two are defensible, but as soon as you install an actual handler it's unusably broken
2020-11-02 20:49:11 <monochrom> Right, I know that.
2020-11-02 20:49:43 <monochrom> I'm a good kid, I use sigaction and make careful decisions about the options, when it's my handler.
2020-11-02 20:50:01 × u0_a298 quits (~user@47.206.148.226) (Ping timeout: 264 seconds)
2020-11-02 20:50:06 → alp joins (~alp@2a01:e0a:58b:4920:ecfe:1146:fdb5:4e48)
2020-11-02 20:50:13 <bqv> ah wait
2020-11-02 20:50:24 <monochrom> And those fields are actually useful for handlers.
2020-11-02 20:50:49 <bqv> no, even with strace i should at least see the handler installed, right?
2020-11-02 20:50:58 <bqv> what is going on...
2020-11-02 20:51:04 <tomsmeding> with 'strace -f' yes
2020-11-02 20:51:09 <bqv> why -f?
2020-11-02 20:51:13 <bqv> i don't fork
2020-11-02 20:51:15 <geekosaur67> follow forks
2020-11-02 20:51:20 <tomsmeding> your children do
2020-11-02 20:51:24 <geekosaur67> but the parent does, you said?
2020-11-02 20:51:30 <tomsmeding> that
2020-11-02 20:51:33 <tomsmeding> sorry
2020-11-02 20:51:41 <bqv> i'm running `launcher -- strace program`
2020-11-02 20:51:50 <bqv> so strace's immediate child should be traced
2020-11-02 20:51:50 <tomsmeding> use -f anyway to be sure :p
2020-11-02 20:52:00 <bqv> but then i end up tracing x11 ;_;
2020-11-02 20:52:02 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 260 seconds)
2020-11-02 20:52:06 <bqv> that's ..not pretty
2020-11-02 20:52:10 <tomsmeding> which might very well be the culprit
2020-11-02 20:52:16 <tomsmeding> use -ff perhaps
2020-11-02 20:52:26 <bqv> see you in a minute or two...
2020-11-02 20:52:28 <tomsmeding> splits out the log for separate processes
2020-11-02 20:52:49 <monochrom> -fff and -ppp...
2020-11-02 20:53:49 <bqv> oh good god that's too many processes
2020-11-02 20:54:05 <bqv> but at least now i have some hits for USR1
2020-11-02 20:54:31 <bqv> 149, to be exact
2020-11-02 20:54:32 <monochrom> P.S. I am a robot and I always tried to train myself to have 10 levels of consistent strength for the range from ppp to fff.
2020-11-02 20:54:43 <tomsmeding> you may also like --trace for strace, or just rely on good-old grepping (better)
2020-11-02 20:55:06 <bqv> yeah, it's ok, i'm in emacs, so i can just smartly grep through this
2020-11-02 20:55:34 <tomsmeding> monochrom: I have the fortune of not being classically trained so I just take those dynamics markings as a general guideline :D
2020-11-02 20:55:37 <bqv> but i have truly no idea how to interpret any of it
2020-11-02 20:55:46 <monochrom> Yeah data scientists recommend saving all data and worrying about mining later.
2020-11-02 20:56:09 <tomsmeding> how many lines is 'grep USR1 *'
2020-11-02 20:56:17 <tomsmeding> $ grep USR1 * | wc -l
2020-11-02 20:56:22 <bqv> 149
2020-11-02 20:56:23 <monochrom> Oh, I think classical music people also take liberty. They too are against my robotic way.
2020-11-02 20:56:34 <tomsmeding> bqv: pastebin plz
2020-11-02 20:56:53 <monochrom> Or at least, fff for one piece don't have to be the same as fff for another piece.
2020-11-02 20:57:03 <tomsmeding> makes sense
2020-11-02 20:57:14 × Aquazi quits (uid312403@gateway/web/irccloud.com/x-onbapdmfluqaidcp) (Quit: Connection closed for inactivity)
2020-11-02 20:57:24 <tomsmeding> some composers are less liberal with their fff's I'd think, rather calling that f or ff
←Prev  Next→
Page 1 .. 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 .. 5022

All times are in UTC.