RustPython doesn't use GIL at all. RustPython use individual lock for each data type. So RustPython has more multithreading bugs.

You mean more multithreaded bugs are possible in the Python code that it's running, right? Not that RustPython itself has more multithreading bugs?

RustPython itself has more bugs. e.g. `dict()` doesn't work well on some multithread scenario yet.

Why does rust python need to use Gil

Is it an artificial artifact or is it necessary to make rust python work?

Windows utility. Working for AMD chips with multiple L3 cache clusters.

By the developer, it boosts stellaris 50%.

preview: https://twitter.com/js1024fun/status/1547183423239897089

This is insane.

Thanks. I didn't think adding them to the why page. For now, the actual projects work like:

  if DEBUG:
      ring_cache = functools.partial(ring.dict, {}, default_action='execute')
  else:
      ring_cache = functools.partial(ring.redis, client)

  @ring_cache(...)
  def ...

Which is not very good solution at all. I will fix the design and properly document it. Thanks for suggesting why page and mock section.

agree

Thanks, I will fix it

I agree they are missing features but still they are easy goal with small refactoring so it will be solved soon. Issue #129 is about application default. After that, dryrun is just replacing default action from 'get_or_update' to 'execute'

Will it be correct expression if I fix it to outside? https://github.com/youknowone/ring/pull/133/files

Yeah, I commented on the PR as such.

no dogpile lock but get_or_create exists with different name: get_or_update

I want to say "not yet". It is shame that I didn't know docpile lock.