Re: Thread State and the Global Interpreter Lock

Discussion in 'Python' started by Aahz, Jun 28, 2003.

  1. Aahz

    Aahz Guest

    In article <3ef8b9b2$>, Ryjek <> wrote:
    >
    >Our application currently consists of two processes: one is a database
    >and one is a windowing program with a user interface. Both embed a
    >Python interpreter for customization purposes (i.e. you can write your
    >own GUI extensions, and your own database procedures).
    >
    >I would like to merge both processes into one process with two threads
    >(mostly for performance purposes), but keep both threads' data separated
    >the same way as they are now. Python practically does not allow me to do
    >it because it insists that only one thread can execute Python bytecodes
    >at a time. I would like to be able to run both interpreters in
    >completely separate environments, where no state and no objects are
    >shared. I believe the restriction of "one thread at a time" is too
    >strict in such cases. What is the purpose of Py_NewInterpreter() if you
    >cannot run it concurrently ..?


    It was a mistake, essentially, kept around for the rare occasions when
    the caveats below don't apply.

    I would say that if performance is your primary goal, multi-threading
    your application would be a poor idea. Threads work best in two
    contexts: breaking up similar types of work for performance (and in the
    case of Python, that pretty much needs to be I/O work), and increasing
    the responsiveness of user-centered applications. Unless you're sharing
    huge amounts of data, it's quite likely that even outside of Python you
    wouldn't see much (if any) performance increase.

    >I understand that making Python completely thread safe w.respect to
    >native threads may not be appropriate, but it shouldn't be that
    >difficult to allow for real concurrent execution in isolated
    >environments. At least, this is what they did in Perl:
    >http://www.icewalkers.com/Perl/5.8.0/lib/threads.html


    The problem is that Python relies heavily on DLLs, both internally and
    third-party libraries. It's pretty much impossible to set things up so
    that random DLLs can be correctly loaded by multiple interpreters in a
    single process.

    Because threading has existed in core Python for many years, a lot of
    bugs and issues have been hashed out -- it's not at all clear to me the
    extent to which Perl has done the same. One reason why Python sticks
    with the GIL model is that multi-threading does diddly-squat for
    computational threads on a single-CPU box. It's actually *more*
    efficient the way Python does it.
    --
    Aahz () <*> http://www.pythoncraft.com/

    Usenet is not a democracy. It is a weird cross between an anarchy and a
    dictatorship.
    Aahz, Jun 28, 2003
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fuzzyman
    Replies:
    3
    Views:
    476
    Andrew MacIntyre
    Dec 5, 2003
  2. Tomas Christiansen

    Global Interpreter Lock

    Tomas Christiansen, Sep 24, 2004, in forum: Python
    Replies:
    3
    Views:
    297
    Michael Hoffman
    Sep 24, 2004
  3. Paul Rubin

    global interpreter lock

    Paul Rubin, Aug 19, 2005, in forum: Python
    Replies:
    59
    Views:
    1,276
    Michael Sparks
    Sep 15, 2005
  4. Replies:
    2
    Views:
    271
  5. Duncan Grisby
    Replies:
    0
    Views:
    278
    Duncan Grisby
    Nov 18, 2005
Loading...

Share This Page