Make CPython segfault in 5 lines of code

Re:Make CPython segfault in 5 lines of code by Thorrez on Wednesday December 18, 2019 @11:10PM (#21831965)

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.

[ Parent | on HN ]

Re:Make CPython segfault in 5 lines of code by loeg on Thursday December 19, 2019 @03:32AM (#21833065)

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.

[ Parent | on HN ]

Re:Make CPython segfault in 5 lines of code by h2odragon on Thursday December 19, 2019 @09:14AM (#21835035)

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.

[ Parent | on HN ]

Re:Make CPython segfault in 5 lines of code by PixyMisa on Thursday December 19, 2019 @09:29AM (#21835166)

It was also terribly slow.

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

[ Parent | on HN ]

Re:Make CPython segfault in 5 lines of code by loeg on Friday December 20, 2019 @03:22AM (#21842481)

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.

[ Parent | on HN ]