By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,876 Members | 1,206 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,876 IT Pros & Developers. It's quick & easy.

Is email package thread safe? (fwd)

P: n/a

(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

--
http://mail.python.org/mailman/listinfo/python-list
Jul 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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.

--
Regards,

Diez B. Roggisch
Jul 18 '05 #2

P: n/a
Op 2005-02-09, Roman Suzi schreef <rn*@onego.ru>:

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

--
Antoon Pardon
Jul 18 '05 #3

P: n/a
On Wed, 9 Feb 2005, Antoon Pardon wrote:
Op 2005-02-09, Roman Suzi schreef <rn*@onego.ru>:

Just to be sure, is email package of Python 2.3 thread-safe or not
(to use, for example, in python-milter?) 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.


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
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3
Jul 18 '05 #4

P: n/a
Op 2005-02-09, Roman Suzi schreef <rn*@onego.ru>:
On Wed, 9 Feb 2005, Antoon Pardon wrote:
Op 2005-02-09, Roman Suzi schreef <rn*@onego.ru>:

Just to be sure, is email package of Python 2.3 thread-safe or not
(to use, for example, in python-milter?) 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.


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.

--
Antoon Pardon
Jul 18 '05 #5

P: n/a
On Thu, 10 Feb 2005, Antoon Pardon wrote:
Op 2005-02-09, Roman Suzi schreef <rn*@onego.ru>:
On Wed, 9 Feb 2005, Antoon Pardon wrote:
Op 2005-02-09, Roman Suzi schreef <rn*@onego.ru>:

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

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.


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.


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
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3
Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.