Do I need a lock here?

[jasiu85]

Hey,

Please take a look at the code of the two threads below:

COMMON_DICT = {}

def thread_1():
global COMMON_DICT
local_dict = prepare_dict()
COMMON_DICT = local_dict

def thread_2():
global COMMON_DICT
local_dict = COMMON_DICT
use_dict(local_dict)

Do I need a lock to protect the COMMON_DICT dictionary? AFAIK bytecode
operations are atomic and in each thread there's only one crucial
bytecode op: STORE_NAME in the first thread and LOAD_NAME in the
second one. So I suspect that everything will work just fine. Am I
right?

Regards,

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

Re: Do I need a lock here?

[jasiu85]

On Oct 27, 10:12 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> jasiu85 schrieb:
>
>
>
> > Hey,
>
> > Please take a look at the code of the two threads below:
>
> > COMMON_DICT = {}
>
> > def thread_1():
> >     global COMMON_DICT
> >     local_dict = prepare_dict()
> >     COMMON_DICT = local_dict
>
> > def thread_2():
> >     global COMMON_DICT
> >     local_dict = COMMON_DICT
> >     use_dict(local_dict)
>
> > Do I need a lock to protect the COMMON_DICT dictionary? AFAIK bytecode
> > operations are atomic and in each thread there's only one crucial
> > bytecode op: STORE_NAME in the first thread and LOAD_NAME in the
> > second one. So I suspect that everything will work just fine. Am I
> > right?
>
> Depending on what you mean by "right".
>
> The above is not enough to judge what is really happening. But depending
> on the execution order, thread_1 overwrites the reference in COMMON_DICT
> *after* thread_2 has altered it.
>
> But it won't crash or anything. If that's right for you.
>
> Diez

The second thread doesn't alter the dictionary, it only reads it. Even
if the first thread puts a reference to a new dictionary into the
COMMON_DICT variable while the second thread is reading the old
dictionary, such sematics is fine for me. I'm seeking for a kind of
Producer/Consumer pattern. So the first thread produces some data in a
form of a dictionary. The second thread reads it from time to time.
It's sufficient for me if a dictionary is "lost" because the first
thread overwrites the COMMON_DICT variable before the second thread
tries to read it. It's also sufficient for me if the first thread
updates COMMON_DICT variable while the second thread is reading the
previous copy of the dictionary. So from my point of view the most
critical parts are these two lines:

COMMON_DICT = local_dict # in the first thread
local_dict = COMMON_DICT # in the second thread

Can these two instructions by any chance interfere with each other in
a way that will crash either of the threads?

I hope I made myself a little bit more clear :).

Thanks!!

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

encoding in lxml

[jasiu85]

Hey,

I have a problem with character encoding in LXML. Here's how it goes:

I read an HTML document from a third-party site. It is supposed to be
in UTF-8, but unfortunately from time to time it's not. I parse the
document like this:

html_doc = HTML(string_with_document)

Then I retrieve some info from the document with XPath:

xpath_nodes = html_doc('/html/body/something')

Now I'm guaranteed that the xpath_nodes list contains only one
element. So I read it's content:

xpath_nodes[0].text

And I get exception here. The exception is coming from the text
property of an Element object. The problem is that the text contains a
non-utf8 character. LXML seems to be using strict decoding and I can't
find a way to make it ignore the error. Is there anything I can do to
retrieve the text without getting an exception?

Regards,

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