<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
01:40 irclogger_com joined
01:40 Topic for
03:48 claw joined
04:58 glennpratt joined
06:42 glennpratt joined
13:37 <Bish> is there any way to use sequel with fork?
13:38 <Bish> as in fork { DB.tables }
13:38 <Bish> shouldn't i do that?
13:43 <Bish> fork { DB.disconnect } seems to work
13:49 <Bish> found a thread where jeremy "advices" exactly that
13:50 <Bish> one question though: the documentation of #disconnect says "connections in use aren't disconnected"
13:51 <Bish> will "active" connections of the forker get copied and result in still having "buggy" connections?`
13:52 <Caesium> sure, you can fork then re-use a sequel object, but you must call DB.disconnect first (as I suspect you found)
13:52 <Caesium> so the database handle isn't shared between processes (which will fuck things up royally)
13:52 <Caesium> the next query in the new process will just open a new handle
13:53 <Caesium> not sure about the answer to the active ones. usually this is used as part of appserver preloading, ie unicorn starting 4 workers then all doing DB.disconnect so they all get their own handle
13:54 <Bish> well i guess that's why jeremy says "call DB.disconnect after startup, but before selects"
13:54 <Caesium> yep
13:54 <Bish> cool, i am happy that i can fork
13:54 <Caesium> yeah, thats definitely a supported thing
13:54 <Bish> im coding for quite a while.. never used fork
13:55 <Bish> but should be used in ruby, i guess
13:55 <* Bish> wished multicores were already a thing when matz built ruby
13:55 <Caesium> depends on the use case, you can fork or thread :)
13:56 <Bish> well, threading almost always sucked for me in ruby, i tried to a lot around that
13:56 <* Freaky> uses JRuby, no forking, but threads work
13:56 <Caesium> threading got a lot better in recent rubies but I'm no expert
13:56 <Bish> i tried jruby too, but everything i tried was more pain in the a as mri
13:56 <Freaky> also if you're in a threaded app you should probably avoid forking
13:56 <Bish> guess forking is a nice way around that
13:56 <Bish> im just trying to speed up my database workers
13:56 <Freaky> it's one of these things that's very difficult to do safely (which is why JRuby doesn't do it)
13:57 <Bish> they only have 1 thread
13:57 <Bish> but i want multiple of them, so i guess fork is the way to go
13:58 <Freaky> MRI always threads these days I think, I assume they're jumping through all the hoops the right way to make forking safe
13:59 <Freaky> but it wouldn't particularly surprise me if it only works by accident
13:59 <* Freaky> glares at Timeout
14:03 <Freaky> Bish: what sort of database workers? doing real work in Ruby? Or just asking the db lots of concurrent questions?
14:03 <Bish> things like csv imports..
14:03 <Bish> things i am to stupid to write in pgsql triggers
14:08 <Bish> so yes, real work
14:09 <Bish> that's my note for the future
14:09 <Bish> if you can implement something in database triggers, freakin do it
14:13 <Bish> i should give jruby another shot..
14:13 <Bish> for performance sake
14:33 <Bish> Caesium: well, but i need to fork before any cmd was sent to the database
14:34 <Bish> what do i do.. if i want to select jobs from database, and then work on the
14:34 <Bish> i certainly do a select before then.. which fucks with sequel
14:37 <Freaky> see concurrent-ruby if you're going to try JRuby, often better than handling threads yourself
14:38 <Freaky> you might just stuff your work in an array of Futures and not even really think about the thread pool they're running on
14:39 <Bish> right now i am trying the fork approach
14:39 <Bish> but i will!
14:42 <Freaky> it's far from perfect, occasional odd threading bugs, some gems aren't available, the replacements aren't always drop-in, and the startup times are pretty obnoxious
14:44 <Bish> so i am not going to do it
14:44 <Freaky> memory use can be higher too, but if you're doing stuff concurrently that tends to get amortized because you're running one copy with a bunch of threads and not a bunch of copies with one thread
14:46 <Freaky> plus long-running processes benefit from the compacting GCs, don't suffer as much from fragmentation
14:47 <Bish> man cs is such a hazzle
14:47 <Freaky> looking at FreshBSD, v3 which is MRI has 4 puma workers of 1.5GB each - v4 which is JRuby has one worker of 2GB
16:56 glennpratt joined
17:23 ben__ joined
17:38 <adam12> Freaky: FreshBSD yours?
18:41 GitHub97 joined
18:41 <GitHub97> [13sequel] 15jeremyevans commented on issue #1349: Looks good, thanks for the patch! 02https://git.io/v9wAG
18:41 GitHub97 left
18:42 GitHub186 joined
18:42 <GitHub186> [13sequel] 15jeremyevans pushed 1 new commit to 06master: 02https://git.io/v9wAZ
18:42 <GitHub186> 13sequel/06master 148a4193b 15Mark Allen: Fix arguument typo
18:42 GitHub186 left
18:42 GitHub45 joined
18:42 <GitHub45> [13sequel] 15jeremyevans closed pull request #1349: Fix arguument typo in deprecation message (06master...06patch-1) 02https://git.io/v9wTJ
18:42 GitHub45 left
18:55 <Freaky> adam12: yep
19:00 <adam12> Freaky: Cool. I saw it mentioned somewhere a few weeks ago (a jruby thread, I think)
19:04 <Freaky> adam12: where was that?
19:04 <adam12> Freaky: I don't remember :\ but I ended up on the site browsing around.
19:04 <adam12> Very cool.
19:05 <Freaky> it does pretty well for a thin layer around elasticsearch :)
19:36 <adam12> Freaky: nice :)
22:11 Quintasan joined
22:11 Quintasan joined
22:16 eregon_ joined
22:21 jhass|off joined
22:48 <Bish> jeremyevans: how do i correctly fork, when i already have done selects?
23:28 ben__ joined
23:51 glennpratt joined