<yorickpeterse>
haven't seen that one pop up since though
<yorickpeterse>
but yeah
<yorickpeterse>
lets close all IOs!
<brixen>
yxhuvud: this cost me 2 hrs of debugging yesterday
<yxhuvud>
brixen: lol. that is simply mean
elia has joined #rubinius
<yorickpeterse>
Hmpf, 3,85% spent in rb_enc_associate
<brixen>
yorickpeterse: is anyone using this daemon-kit thing?
<yorickpeterse>
brixen: yes
<yorickpeterse>
e.g. we are, for now
<yorickpeterse>
I'm pretty close to getting it out code wise
<yxhuvud>
brixen: at least that is explicit though. my experience was a single io controlled by one c lib being closed by a c lib ..
<yorickpeterse>
we really only use it for PID management nowadays, everything else is set up in a way that it doesn't depend on daemon-kit
<yxhuvud>
*another c lib
<brixen>
yxhuvud: yeah, the fd aliasing bullshit is fun
<brixen>
at least daemon-kit is only looking at IOs
<brixen>
which is a teensy tiny bit better than god's approach
<brixen>
but still completely terrible
<yorickpeterse>
I never got where this cargo culting originated from though
<brixen>
equal orders of terrible, both approximately comparable to infinitely terrible
<yorickpeterse>
There are plenty of IOs that don't have to be re-opened after a fork
<yorickpeterse>
or IOs that can do this themselves
<yorickpeterse>
e.g. I think Dalli has some stuff to reconnect/reopen after a fork
<yorickpeterse>
then again it's written by mperham, who at least knows his Unix
<yorickpeterse>
and Ruby
<yorickpeterse>
bah, I wish Ruby had a ByteString of some sort
<yorickpeterse>
(across all implementations)
<yorickpeterse>
It would allow me to allocate that instead of a String, and only allocate the latter upon access
<yorickpeterse>
which, in theory, could be faster
<brixen>
yxhuvud: doubling down on the crazy in this case, that god close was closing the logging fd as well
<brixen>
so when debugging, I didn't see any indication in the log of the issue
<yxhuvud>
hihi
<yorickpeterse>
ha
<yorickpeterse>
That's what you get for putting a logger in Rbx
<brixen>
it wasn't until noticing *another* thread writing to the log that I realized I wasn't seeing any logging
<brixen>
yeah, silly silly
<yorickpeterse>
But this works in MRI so it's totally a bug in Rbx
<yorickpeterse>
:>
<brixen>
basically
<yxhuvud>
in my case it was a testing framework, which sometimes lost connection to the config gui. except it was a client for something totally different that closed it.
<brixen>
about 50% of what works in MRI is a bug, so...
<yorickpeterse>
just happy little accidents
<yorickpeterse>
or as Linus said: "If people rely on it it's a feature, not a bug" :P
DanielVartanov_ has joined #rubinius
DanielVartanov_ has quit [Ping timeout: 258 seconds]
DanielVartanov has joined #rubinius
<yorickpeterse>
oh hey, Ruby's profiler is contradicting data from Valgrind
<yorickpeterse>
MRI reports 17,28% is spent in Proc#call
<yorickpeterse>
Valgrind reports 0,66% is spent in proc_call
DanielVartanov has quit [Ping timeout: 255 seconds]
elia has quit [Quit: Computer has gone to sleep.]
pietr0 has joined #rubinius
goyox86 has joined #rubinius
max96at is now known as max96at|off
elia has joined #rubinius
carlosgaldino has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
josh-k has quit [Ping timeout: 240 seconds]
tenderlove has joined #rubinius
josh-k has joined #rubinius
17SAAYP59 has quit [Ping timeout: 244 seconds]
elia has quit [Quit: Computer has gone to sleep.]
josh-k has quit [Ping timeout: 264 seconds]
elia has joined #rubinius
josh-k_ has joined #rubinius
havenwood has quit [Remote host closed the connection]
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]