<Synthead>
I highly recommend reading up on concurrent-ruby
Guest7375 has joined #ruby
Rounin has joined #ruby
SteveR has quit [Ping timeout: 256 seconds]
teclator has joined #ruby
Synthead has quit [Quit: Leaving]
oxfuxxx has joined #ruby
ur5us has joined #ruby
<skandal>
Hello.
<skandal>
How i can extend erb file with base.erb ?
duds- has quit [Remote host closed the connection]
duds- has joined #ruby
reset has quit [Quit: reset]
Furai has quit [Remote host closed the connection]
Furai has joined #ruby
justAstache has quit [Read error: Connection reset by peer]
justAstache has joined #ruby
constxd_ has quit [Ping timeout: 240 seconds]
jhass has quit [Ping timeout: 250 seconds]
gproto23 has joined #ruby
dionysus69 has joined #ruby
dionysus69 has quit [Client Quit]
nmollerup has quit [Ping timeout: 268 seconds]
jhass has joined #ruby
roadie has quit [Quit: ERC (IRC client for Emacs 25.3.50.1)]
fercell has joined #ruby
ur5us has quit [Ping timeout: 240 seconds]
dionysus69 has joined #ruby
dionysus69 has quit [Client Quit]
dionysus69 has joined #ruby
dionysus69 is now known as help
help is now known as dionysus69
sylario has joined #ruby
nmollerup has joined #ruby
wand has quit [Remote host closed the connection]
wand has joined #ruby
infinityfye has joined #ruby
mahlon_ has quit [Ping timeout: 252 seconds]
ged has quit [Ping timeout: 256 seconds]
constxd has joined #ruby
bluedust has joined #ruby
unyu has joined #ruby
fandre1986 has joined #ruby
bluedust_ has joined #ruby
bluedust has quit [Ping timeout: 245 seconds]
oxfuxxx has quit [Quit: Yankies Motherfh@ckers C0[k Astroboys]
TCZ has joined #ruby
bluedust_ has quit []
TCZ has quit [Quit: Leaving]
<constxd>
kings
<constxd>
can anyone explain to me why the first thread finishes running before the second one starts? http://paste.pr0.tips/Ns
<constxd>
sorry if someone answered earlier i fell asleep any my laptop died so i couldn't check the channel history
TCZ has joined #ruby
<jhass[m]>
constxd: Because your function doesn't do any IO or otherwise blocking operation handled outside the RubyVM. MRI (the main ruby implementation) has a global lock around executing Ruby code. In Ruby 3 this was lessened somewhat by the introduction of Ractors which you could use instead of threads but which impose limits on data sharing between them
<constxd>
yeah but even with a GIL can't you interleave execution?
<jhass[m]>
Only if there was a reason to release the GIL, which doesn't happen until there's a blocking operation that causes a release
<ox1eef>
because of the shared state you're writing to concurrently
<constxd>
it's protected by the GIL though
<ox1eef>
the gil is implementation specific, and afair it does not save you from thread safety issues like that.
<constxd>
cringe
<constxd>
first they rob u of true parallelism with the gil then they tell u u can't even rely on it?
<ox1eef>
if you want that there's other ruby impls without it, and there's Process#fork too
<ox1eef>
sorry Kernel#fork
<constxd>
is it possible to actually trigger undefined behavior in MRI using threads in ruby?
<constxd>
like actual unsafe code not just incorrect code
<ox1eef>
i dont think so, that sounds like a C worry - not a ruby one.
<ox1eef>
you can still have race conditions though
<constxd>
is that why the GIL exists
<constxd>
just to make sure nothing is truly unsafe
<ox1eef>
as far as i understood, the GIL makes life easier in C and C extensions.
<ox1eef>
it's an implementation detail.
<ox1eef>
jruby for example doesnt have it.
<constxd>
my language has no GIL but a consequence of that is that you can easily make the runtime segfault by writing incorrect multithreaded code so it shifts the burden to the user
<ox1eef>
cool
<constxd>
if only jvm wasn't so big and heavy jruby sounds pretty sick
<ox1eef>
personally not my thing. i hate the jvm.
<constxd>
given the sheer amount of ruby code out there, even at large companies, i'm surprised nobody has built a new ruby vm from the ground up
<ox1eef>
it's a huge effort, there have been attemts, some abandoned, some not
<constxd>
imagine the amount of engineering power that has gone into v8 being put into ruby
<ox1eef>
rubinius was really cool for a time but more or less dead now, or at least diverged into something else entirely - not even strictly ruby anymore.
szkl has joined #ruby
roadie has joined #ruby
<mooff>
if JRuby has no GIL, is its Array, Hash, Object etc thread safe?
TCZ has quit [Quit: Leaving]
<ox1eef>
i don't believe so. i think concurrent_ruby or some other lib providing thread-safe data structures is recommended. that may have changed, i dont follow jruby closely.
<ox1eef>
i think it's a stroke of fate that i dont find jruby useful. i'm a fan of fork, and the JVM does not support it. that and other differences with MRI drove me away.
<constxd>
ah yeah that is very very cringe
<constxd>
multiple processes with good IPC is nice way to solve a lot of problems
<ox1eef>
yeah i love that mode of development
<ox1eef>
or style, i guess
<ox1eef>
still though, jruby deserves credit for those in the java and jvm world, you can interface with jvm pretty well and have all the tooling & libs that come with it.
roadie has quit [Quit: ERC (IRC client for Emacs 25.3.50.1)]
<mooff>
Ruby on Spring Boot 😎
<ox1eef>
i know of Spring as a java web framework, what is Spring Boot?
<jhass[m]>
Actor model (and thus Ractors, basically) is pretty much the multi process + IPC model without the multi-process overhead
<mooff>
ox1eef: some new thing to make it less awkward to deploy and use
<constxd>
jhass[m]: yes which makes it a good alternative to fork() but a bad alternative to proper threads
<ox1eef>
i was reading about spring, it does not seem to strictly be a web framework but a collection of things, one of which can be used for the web?
<ox1eef>
jhass[m]: good to know, but when you have copy-on-write, is the overhead that much?
taupiqueur has joined #ruby
<mooff>
if you have somewhat proper threads, but no fork, is the downside that much? :)
<jhass[m]>
depends on your usecase (and OS, somewhat) always. Certainly can spam a lot more actors than processes
<constxd>
what can you send between Ractors
<jhass[m]>
Also consider Kernel managed swapping vs application (runtime) managed if you'd built your actor implementation on top of coroutines
<ox1eef>
mooff: i guess it depends, the unix API is what i enjoy to use. i havent checked out actors though. i will look into that.
<jhass[m]>
Haven't really looked at Ractors yet, but I thought each runs in its own thread?
<jhass[m]>
so they're basically full threads sans shared state, I think?
<ox1eef>
thats my understanding, i also havent looked into them deeply.
<jhass[m]>
so I'd expect you can send anything, Ruby just tracks which object is owned by what ractor or something like that, I would guess
<mooff>
i wish enabling hostname + peer verification was easier with OpenSSL in Ruby
<ox1eef>
thats a limitation in the IPC model, at least if you want to send objects between processes. at best, you can send what Marshal can serialize.
<mooff>
i hoped to avoid this library having anything to do with dialing - you just give it an IO object as its socket
<mooff>
that's neat for plain connections, but SSL with verification takes four or five lines that are hard to discover
<ox1eef>
mooff: i guess it is like curses, a one-to-one mapping of the C API?
<jhass[m]>
> When an unshareable object is sent, it can be either copied or moved.
<mooff>
ox1eef: you have to make a context, make an X509 store, ask the X509 store to set its paths to the system defaults, set the store as the store for the context, *then* make a socket with that context
<ox1eef>
good to know :)
<adam12>
morning
<mooff>
i think i left out telling the context what hostname it should verify, and therefore it may succeed w/o verifying it, silently
<ox1eef>
gmorning
<ox1eef>
mooff: ah thats definitely bad.
<mooff>
ox1eef: it's too much to ask someone to do in bot scripts!
<ox1eef>
i agree, but theyre not at the socket level are they?
<mooff>
i'd gotten away with sock = OpenSSL::SSL::SSLSocket.new(Socket.tcp(host, port)).tap(&:connect) for brevity, but that does no verification
<mooff>
i wanted 'iirc' not to be responsible for dialing