01:34 <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]

01:43 <FromGitter> <3n-k1> or would i have to box it and use atomic?

02:39 <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.

02:50 <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?

02:56 <FromGitter> <naqvis> yeah

02:56 <FromGitter> <3n-k1> awesome, ty

03:38 <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

03:44 <FromGitter> <naqvis> @3n-k1 by default Crystal is single threaded unless you use the experimental/preview parallelism feature

03:45 <FromGitter> <naqvis> but its unsafe to share RW area in concurrent code

03:47 <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`

03:48 <FromGitter> <naqvis> btw, not all of the stdlib is thread-safe

03:52 <FromGitter> <3n-k1> alright so, how would i avoid shared memory? this is my first time really diving into fibers

03:52 <FromGitter> <3n-k1> @Blacksmoke16 https://rosettacode.org/wiki/Active_object

03:53 <FromGitter> <3n-k1> it's an active object integrating a function using the trapeze method

03:53 <FromGitter> <Blacksmoke16> Hmm fair enough

03:54 <FromGitter> <naqvis> https://crystal-lang.org/reference/guides/concurrency.html should give you enough details on Crystal concurrency functionality and its how-tos

03:59 <FromGitter> <3n-k1> ty

04:05 <FromGitter> <3n-k1> so basically, i should be initializing the object in a different fiber, right?

04:07 <FromGitter> <3n-k1> that would stop the shared memory issue?

04:47 <FromGitter> <naqvis> yeah

04:47 <FromGitter> <naqvis> but as i said, in ST mode, things as of now, will work just fine

04:48 <FromGitter> <naqvis> but you will start receiving strange issues/problems at different intervals when you start doing the parallelism

08:23 <FromGitter> <HertzDevil> going through the backlog of splat-related issues and discovering new ones that nobody else has reported

10:24 <hightower2> HertzDevil ++

13:16 <FromGitter> <3n-k1> is appending to a file atomic, or would i need to lock it?

13:19 <FromGitter> <asterite> I don't think it's atomic, or at least there's flock

13:23 <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

13:25 <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

13:25 <riffraff169> use a/a+ for append, that should be atomic

13:26 <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

13:34 <FromGitter> <3n-k1> everything is nicer when i pretend multitasking doesn't exist haha

13:44 <riffraff169> yeah thats right