Is email package thread safe? (fwd)

[Roman Suzi]

(this is a repost with an addition - probably noone noticed my message first
time)

Hi!

Just to be sure, is email package of Python 2.3 thread-safe or not
(to use, for example, in python-milter?)

P.S. And where can I find information on particular piece of standard library
if it is thread-safe or need locking? I recall 'random' module is (was?)
unsafe - which isexplicitly stated in the docs. Can I assume that everything
else without such notice is thread-safe?

Sincerely yours,
Roman A.Souzi

 

[Antoon Pardon]

(this is a repost with an addition - probably noone noticed my message first
time)

Hi!

Just to be sure, is email package of Python 2.3 thread-safe or not
(to use, for example, in python-milter?)

P.S. And where can I find information on particular piece of standard library
if it is thread-safe or need locking? I recall 'random' module is (was?)
unsafe - which isexplicitly stated in the docs.

Well I guess it was unsafe. The current documentation states:

The underlying implementation in C is both fast and threadsafe.

http://www.python.org/doc/2.3.5/lib/module-random.html

There is class for random number generation that is not thread safe
and is included to allow reproducing sequences from previous versions.

Can I assume that everything
else without such notice is thread-safe?

I doubt it. There is no indication that the email package uses any
kind of locking. So multiple thread working on the same message
will probably screw things up.

 

[Diez B. Roggisch]

Usually, oo-style apis are thread-safe as long as each thread uses its own
objects. Shared global state is _very_ uncommon, and if it's most probably
documented.

 

[Roman Suzi]

I doubt it. There is no indication that the email package uses any
kind of locking. So multiple thread working on the same message
will probably screw things up.

Of course, I do not let threads to work on the same message!
I meant that the package doesn't pose other kinds of restrictions.
Can it work in _any_ situation work on two different messages at the same
time, without any interference?


Sincerely yours, Roman Suzi

 

[Antoon Pardon]

Of course, I do not let threads to work on the same message!

Why should that be: "off course"? The random module you spoke about
was also only thread unsafe if you called the same random generator
from various threads. Using a randon generator per thread shouldn't
have been a problem. Since you mentioned that, I thought that was
the kind of thread safety you were after.

I meant that the package doesn't pose other kinds of restrictions.
Can it work in _any_ situation work on two different messages at the same
time, without any interference?

I can't give a guarantee, but there are no global statements and there
doesn't seem to be assignments to cross module variables I think it
would be a safe bet.

 

[Roman Suzi]

Why should that be: "off course"? The random module you spoke about
was also only thread unsafe if you called the same random generator
from various threads. Using a randon generator per thread shouldn't
have been a problem. Since you mentioned that, I thought that was
the kind of thread safety you were after.


I can't give a guarantee, but there are no global statements and there
doesn't seem to be assignments to cross module variables I think it
would be a safe bet.

Thanks to all who discussed this. Really, I had the same thoughts about
1:1 object-thread relation being thread safe. I am doing further research and
if it will give interesting results, I shall post [solved] here.

Sincerely yours, Roman Suzi