jhass changed the topic of #crystal-lang to: The Crystal programming language | https://crystal-lang.org | Crystal 0.35.1 | Fund Crystal's development: https://crystal-lang.org/sponsors | GH: https://github.com/crystal-lang/crystal | Docs: https://crystal-lang.org/docs | Gitter: https://gitter.im/crystal-lang/crystal
<FromGitter> <3n-k1> ```code paste, see link``` ⏎ ⏎ is reassigning `ai.k` safe? it ran without issues, but i'm not sure if a more complex implementation would have problems [https://gitter.im/crystal-lang/crystal?at=5ff27088de608143155e7c17]
<FromGitter> <3n-k1> or would i have to box it and use atomic?
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
HumanG33k has quit [Max SendQ exceeded]
HumanG33k has joined #crystal-lang
<FromGitter> <naqvis> @3n-k1 Do not communicate by sharing memory; instead, share memory by communicating. Variable parts of MT code should be communication via channels, and for non thread-safe code implement locking (Mutex like) functionality.
<FromGitter> <3n-k1> @naqvis so would it be sufficient to open a channel, select at the beginning of the loop, and change the function if the channel has a new message?
Volk has joined #crystal-lang
<FromGitter> <naqvis> yeah
<FromGitter> <3n-k1> awesome, ty
f1reflyylmao has joined #crystal-lang
f1refly has quit [Ping timeout: 258 seconds]
<FromGitter> <3n-k1> @naqvis sorry for the ping again. implementing the channel, but i was just wondering: is this basic example thread safe, or no? part of me feels like just updating the reference shouldn't be an issue, but also i'm really not well-read on crystal's underlying mechanics :p
<FromGitter> <naqvis> @3n-k1 by default Crystal is single threaded unless you use the experimental/preview parallelism feature
<FromGitter> <naqvis> but its unsafe to share RW area in concurrent code
<FromGitter> <naqvis> to avoid traps/fallback of concurrency like deadlock, corrupted memory, hard-to-debug problems, you should be avoiding the shared memory as much as possible. Should there be a need to share memory then either use the stdlib provided functionality like `Channel` or implement some locking mechanism via `Mutex`
* FromGitter * Blacksmoke16 is wondering what this class is doing
<FromGitter> <naqvis> btw, not all of the stdlib is thread-safe
<FromGitter> <3n-k1> alright so, how would i avoid shared memory? this is my first time really diving into fibers
<FromGitter> <3n-k1> @Blacksmoke16 https://rosettacode.org/wiki/Active_object
<FromGitter> <3n-k1> it's an active object integrating a function using the trapeze method
<FromGitter> <Blacksmoke16> Hmm fair enough
<FromGitter> <naqvis> https://crystal-lang.org/reference/guides/concurrency.html should give you enough details on Crystal concurrency functionality and its how-tos
<FromGitter> <3n-k1> ty
avane has quit [Quit: ZNC - https://znc.in]
chachasmooth has quit [Ping timeout: 260 seconds]
avane has joined #crystal-lang
chachasmooth has joined #crystal-lang
<FromGitter> <3n-k1> so basically, i should be initializing the object in a different fiber, right?
<FromGitter> <3n-k1> that would stop the shared memory issue?
<FromGitter> <naqvis> yeah
<FromGitter> <naqvis> but as i said, in ST mode, things as of now, will work just fine
<FromGitter> <naqvis> but you will start receiving strange issues/problems at different intervals when you start doing the parallelism
Volk has quit [Quit: See you next time!]
chovy has quit [Quit: leaving]
Dreamer3 has quit [Ping timeout: 272 seconds]
Dreamer3 has joined #crystal-lang
Dreamer3 has quit [Ping timeout: 260 seconds]
Dreamer3 has joined #crystal-lang
_ht has joined #crystal-lang
<FromGitter> <HertzDevil> going through the backlog of splat-related issues and discovering new ones that nobody else has reported
Dreamer3 has quit [Quit: Leaving...]
<hightower2> HertzDevil ++
hightower2 has quit [Ping timeout: 256 seconds]
<FromGitter> <3n-k1> is appending to a file atomic, or would i need to lock it?
<FromGitter> <asterite> I don't think it's atomic, or at least there's flock
<riffraff169> i havent look at the source, but the man page for write(2) says that the adjustment of the file offset and the write operation are performed as an atomic step....as long as the file was opened using O_APPEND
<riffraff169> https://crystal-lang.org/api/0.35.1/File.html#new(filename:Path%7CString,mode=%22r%22,perm=DEFAULT_CREATE_PERMISSIONS,encoding=nil,invalid=nil)-class-method
<riffraff169> use a/a+ for append, that should be atomic
<riffraff169> at least for writing...there is probably a possibility that another process could read in the middle of a write, but that is a different issue really
<FromGitter> <3n-k1> everything is nicer when i pretend multitasking doesn't exist haha
<riffraff169> yeah thats right
_whitelogger has joined #crystal-lang
fifr has joined #crystal-lang
ua_ has quit [Ping timeout: 240 seconds]
ua has joined #crystal-lang
postmodern has joined #crystal-lang
_whitelogger has quit [Ping timeout: 260 seconds]
woodruffw has quit [Ping timeout: 256 seconds]
foxxx0 has quit [Quit: foxxx0]
postmodern has quit [Quit: Leaving]
aquijoule_ has quit [Remote host closed the connection]
teardown_ has quit [Ping timeout: 240 seconds]
Seich has quit [Quit: Gone fishing.]