Show HN: I built a Ruby gem that handles memoization with a ttl

Re:Show HN: I built a Ruby gem that handles memoization with... by JamesSwift on Tuesday April 22, 2025 @03:07PM (#43765253)

Looks good. Id suggest making your `get` wait to acquire the lock until needed. eg instead of

  @lock.synchronize do
    entry = @store[key]
    return nil unless entry

    ...

you can do

  entry = @store[key]
  return nil unless entry

  @lock.synchronize do
    entry = @store[key]

And similarly for other codepaths

[ Parent | on HN ]

Re:Show HN: I built a Ruby gem that handles memoization with... by chowells on Tuesday April 22, 2025 @03:27PM (#43765419)

Does the memory model guarantee that double-check locking will be correct? I don't actually know for ruby.

[ Parent | on HN ]

Re:Show HN: I built a Ruby gem that handles memoization with... by JamesSwift on Tuesday April 22, 2025 @03:40PM (#43765546)

I think it wouldnt even be a consideration on this since we arent initializing the store here only accessing the key. And theres already the check-then-set race condition in that scenario so I think it is doubly fine.

[ Parent | on HN ]

Re:Show HN: I built a Ruby gem that handles memoization with... by hp_hovercraft84 on Tuesday April 22, 2025 @10:06PM (#43768052)

Good call, but I think I would like to ensure it remains thread-safe as @store is a hash. Although I will consider something like this in a future update. Thanks!

[ Parent | on HN ]