Thread Safety

[Clarence Gardner]

[Summarizing]
>Python executes bytecodes atomically, but makes no guarantees beyond that.
>Do you still think you're "threadsafe"?
Nope.

[Tim Pedant (sorry, Peters) :) :) :)]
>It's impossible to say:  "thread safety" is not an absolute judgment, it's
>relative to the invariants your particular algorithm needs to preserve.
Sorry.  The question was wrt not losing any data items appended to
the global lists, given that the function shown is the only place that
the Pending... names are bound (other than initialization).
I should have thought of disassembling the code myself (as another helpful
mailed reply also did).  For some reason, I thought that the tuple-ness
of the construct I used would make a difference.  Why?  Beats me :)

[Aahz]
>That's safe, yes, for as long as the GIL exists.  I personally would
>prefer to use a singleton class instance or a static module variable
>rather than a "global" variable, but that's more a matter of taste.
Just for clarity, I'm assuming you mean for as long as the thread holds
it (rather than, "until Guido removes it"), which really changes your
answer to "That's not safe, no".  Given the need for mutex, I'll change
them to classes, I think.

[Tim]
>In your particular case, why try to be clever at all?  The loop doesn't
>wakeup more than once per 10 seconds, so the cost of a mutex lock/unlock
>pair would be insignificant.  In return, you get certainty.
Of course, I'll need to protect all the additions to the lists, also.
But looking at disassembly of various other code fragments (hey,
disassembling Python is fun!), I see that even if I was using a
pre-extended list and put in work with "Work[x] = NewWork", it still
would need to be protected.

[Tim]
>cleverness-is-the-#1-cause-of-thread-bugs-ly y'rs  - tim
[Clarence, humble]
I totally agree, though I didn't consider relying on atomicity as
extreme (or even any) cleverness.  Of course, being quite mistaken about
the extent of that atomicity was, shall we say, the antithesis of
cleverness.

[Aahz]
>In the end, though, I think I'd most likely split this loop into
>two separate threads and use Queue.Queue() unless you have a specific
>reason for wanting to batch up work every ten seconds.  That would
>guarantee the best response time.
Just to give you more info, the batching is because there can be up to
several hundred work items generated in ten seconds, and the functions
that dispose of them generate a network transaction for each batch.
There is no issue of response time in this case.


>Hey, CVS is open for business!  The only way a new release stablilizes is
>via people *using* it.  People who wait until the final release to report
>bugs are going to have to wait months for relief.
Along those lines, I'm going to repeat a question that I posted about a
week ago that passed without comment on the newsgroup.
The issue is the SSL support in the socket module, which raises an
exception when the reading socket is at EOF, rather than returning an
empty string.
I'm hesitant to call it a "bug", but I wouldn't have implemented it this
way.  There are the names of two people mentioned at the top of
socketmodule.c, but no contact information, so I'm suggesting here that
it be changed to conform to normal file/socket practice.
(SSL was actually added at 2.0, so I'm late to the party with this; mea
culpa, mea culpa.  I delayed trying Python2 because of the extension
rebuilding.)