[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

--
http://mail.python.org/mailman/listinfo/python-list

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

--
Regards,

Diez B. Roggisch

[Antoon Pardon]

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

[Roman Suzi]

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

[Antoon Pardon]

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

[Roman Suzi]

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