<jhass>
waj: just so I understand correctly. Does that mean you want to make applications "multithreaded" by default, that is 2.times do File.open("foo#{i}") do |io| @contents << io.read end end would be concurrent access to shared state?
<waj>
no.. unless yo make an explicit "spawn" there is no concurrency
<waj>
but if you do, every time you make a "read" it wouldn't block the entire process. It would give control to another fiber
<waj>
in fact… at the beginning I'm thinking having just a single worker thread
<waj>
so there would never be concurrency unless you make explicit use of threads
<waj>
but, although concurrency != parallelism, there is still a chance to have shared state among different fibers
<waj>
it would be just like Go
<jhass>
I don't know Go tbh
<waj>
mm… but Go has more than one worker thread
<jhass>
so how would ("accidental") shared state in the new model look like?
<waj>
if you read/write a global variable from a fiber for example
<waj>
that was the motivation for the changes that asterite did in the regex results ;)
<jhass>
well, that's why I used @content there
<waj>
so now the $~, $1, etc… aren't global variables anymore
<waj>
besides global variables, "spawn" works with a block so closured variables are shared state as well
<jhass>
let's try content = ""; 2.times do File.open("foo#{i}") do |io| contents << io.gets end end; would that still be deterministic?
<waj>
yes
<waj>
Int#times is not spawning new fibers so the files are sequentially processed
<jhass>
what would spawn new fibers by default?
<waj>
only the "spawn" method
<waj>
in other words… if you don't use "spawn", everything works exactly the same
<waj>
the difference is… if you make a read in one of the fibers, instead of just blocking it gives control to another fiber waiting to run
bcardiff has quit [Quit: Leaving.]
<waj>
mm… no, because I think it's desirable that HTTP calls are handled at the same time
<jhass>
okay, so I think we arrived at my main concern: I have the feeling (and that might very well be FUD given I did almost zero evented programming yet) that when it's non obvious which stdlib call will result in a concurrent program and which won't, that will make the language more confusing and prone to subtle bugs
<weskinner_>
waj: I missed the beginning of this convo but are you working on non-blocking IO for crystal?
<jhass>
weskinner_: uhm, you didn't join or part in the mid ;)
<jhass>
waj: maybe it is, the question I'm having is whether it's obvious that the block you pass to for example File.open is run sequentially while the callback you pass to HTTP::Server is run concurrently
<waj>
well yes… that should be explicitly documented
<jhass>
and while I agree you want to have the later happen concurrently, it's also the perfect example for where you often access shared state
<jhass>
like a database connection or whatever
<jhass>
or even just a logger
<waj>
exactly
<waj>
but you have the same problems in ruby ;)
<jhass>
so if you're new and coming from something like Ruby, you'll wonder why your logger call there is all messed up all of the sudden
<jhass>
which is why I liked the idea of having separate libraries for the evented stuff, you very explicitly decide to use that mode of operation, and since you decided you're aware
<jhass>
well, stdlib logger being thread safe doesn't defy the general argument :)
<waj>
it doesn't but currently if you write a logger you might want to consider concurrent calls
<jhass>
let's get past the logger, that was just an example
<jhass>
my argument really is that I'm not sure that documentation is sufficient to make a newcomer aware of that fact which in turn might make the experience with language more frustating since you don't understand why it behaves the way it behaves
<jhass>
especially if you mix and mash the modes in stdlib
<waj>
maybe you're thinking the change would much more drastic than what really is
<jhass>
maybe, I said it might be FUD for reason ;)
<waj>
besides the http server I can't easily find another case where concurrency is implicitly started
<waj>
(in the std)
<jhass>
so evented_io.cr will stay as it is?
<jhass>
not replace io.cr?
<waj>
he… evented_io should have gone away long time ago :P
<jhass>
what about socket?
<jhass>
which one will become the default?
<waj>
there would be only one implementation backed by libuv
asterite has joined #crystal-lang
<waj>
but… again, unless you make explicit use of spawns, the calls would behave just linear and blocking like they are right now
<jhass>
mmhkay, FUD then. Thanks for clearing that up
<asterite>
Don't you have the same shared access problems with HTTP::Server using threads?
<jhass>
yes
<asterite>
I think the conclusion that we came with waj is that having shared state is bad, for many reasons
<asterite>
If you are using threads, or fibers, but you share global state, then your are in for trouble
<jhass>
my point is that you easily are not aware that you're using shared state because you might not be aware you're code is run concurrently because other parts of stdlib you used before aren't
<asterite>
So, I don't think the change to evented-io-only will solve these issues
<waj>
Absolutely. Although shared access with fibers and a single worker is often more controllable even without locks