[lucy_gatenby]

Just for fun, here's another one:

  import sys, threading
  def r():
      sys.stdin.buffer.read(1)
  t = threading.Thread(target=r, daemon=True)
  t.start()

[Thorrez]

Here's a Python 2 segfault I ran into recently.

    import sys, threading, time
    
    t = threading.Thread(target=sys.stdin.read, args=(1,))
    t.start()
    time.sleep(1)
    sys.stdin.close()

Run it then after a few seconds press enter. It doesn't segfault in Python 3, but it still doesn't behave how I'd like, because I would like the close() to unblock the read(), but it doesn't unblock the read(), the read() still hangs until it gets some input.

[loeg]

The whole threading library in Python is a mess. Python was designed around single threaded programs with shared-nothing state and the cracks show as you move beyond that. The whole idea of replacing the GIL with... multiple same-process distinct-state Python interpreters with cheap-ish message passing sort of highlights how ugly it gets.

[h2odragon]

Back around python 1.5, there was almost a fork of python where every object had locks, there were memory arenas, and multiprocessing was almost thoughtlessly easy. That and stackless would've been great.

[PixyMisa]

It was also terribly slow.

IronPython did that too, on .Net. It ran around one quarter the speed of CPython.

[loeg]

More recently than that, too, unless I'm misremembering. As sibling commenter points out, such a model is horrifically slow. Lock-for-every-object is too granular to perform well.

[saagarjha]

At least that one is an abort…