Hacker News Reader

Comment by sigjuice | Hacker News Reader

A quick search in bugs.python.org shows several crashes. I don’t know much about Python. Is there anything particularly special about this one?

View on HN

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()

At least that one is an abort…

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.

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.

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.

It was also terribly slow.

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

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.

I read it as related to the "limit Python to 1 million lines so it can be stable."

These two things have nothing to do with each other. The 1 million limit wouldn't have any effect here.

Not necessarily, but I just found it interesting that it wasn't really anything all that crazy - it could in theory be possible to encounter this in a big enough code base that makes heavy use of coroutines and custom exception types.

It is crazy to have a class constructor return something that isn't an instance of the class. That's nonsense code and is unlikely to occur in a codebase of any size, regardless of how often they define custom exception types.

I wouldn't have bothered filing the bug.

The Python interpreter should not segfault for this.

Yes, of course. But is it worth your time to fix it? Probably not.

If I jump on my bed enough, it'd probably break, but I'm not complaining to the manufacturer about the issue.

to re-analogize with tools :

if I used my Snap-On(tm) wrench as a prybar (incorrect usage) and broke it, Snap-On would still replace it in exchange for the broken tool and knowledge of the situation that broke it.

To pretend that a language bug isn't worth reporting because you and your codebases will never encounter it seems short-sighted. Down the line, years from now, who knows what you'll have to do to get something to work. Maybe it'll be something this silly, and you'll be happy that the folks before you encountered it and remediated it.

All that said, from a practical standpoint I agree with you.

If you're doing something wacky, and it turns out as wacky as you thought it would, you're probably attacking the problem from the wrong angle, anyway. I just want to remind everyone that 'wacky' things are required and implemented daily in codebases around the world -- regardless of how bad they smell.

Reply on news.ycombinator.com