On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote:
[...]
> So the end result is that the thread that "updates" the dictionary, and the
> thread that initially *populates* the dictionary are actually running in
> different processes.
If they are in different processes, that would explain why the second
(non)thread sees an empty dict even after the first thread has populated it:
# from your previous post
> Length at get AC: 54 ID: 4524152200 Time: 2017-11-01 09:41:24.474788
> Length At update: 1 ID: 4524152200 Time: 2017-11-01 09:41:24.784399
> Length At update: 2 ID: 4524152200 Time: 2017-11-01 09:41:25.228853
You cannot rely on IDs being unique across different processes. Its an
unfortunately coincidence(!) that they end up with the same ID.
Or possibly there's some sort of weird side-effect or bug in Flask that, when
it shares the dict between two processes (how?) it clears the dict.
Or... have you considered the simplest option, that your update thread clears
the dict when it is first called? Since you haven't shared your code with us,
I cannot rule out a simple logic error like this:
def launch_update_thread(dict):
dict.clear()
# code to start update thread
> In fact, any given request could be in yet another
> process, which would seem to indicate that all bets are off as to what data
> is seen.
>
> Now that I've thought through what is really happening, I think I need to
> re-architect things a bit here.
Indeed. I've been wondering why you are using threads at all, since there
doesn't seem to be any benefit to initialising the dict and updating it in
different thread. Now I learn that your architecture is even more complex. I
guess some of that is unavailable, due to it being a web app, but still.
> For one thing, the update thread should be
> launched from the main process, not an arbitrary UWSGI worker. I had
> launched it from the client connection because there is no point in having
> it running if there is no one connected, but I may need to launch it from
> the __init__.py file instead. For another thing, since this dictionary will
> need to be accessed from arbitrary worker processes, I'm thinking I may need
> to move it to some sort of external storage, such as a redis database
That sounds awful. What if the arbitrary worker decides to remove a bunch of
planes from your simulation, or insert them? There should be one and only one
way to insert or remove planes from the simulation (I **really** hope it is a
simulation).
Surely the right solution is to have the worker process request whatever
information it needs, like "the next plane", and have the main process
provide the data. Having worker processes have the ability to reach deep into
the data structures used by the main program and mess with them seems like a
good way to have mind-boggling bugs.
> Oy, I made my life complicated :-)
"Some people, when confronted with a problem, think, 'I know, I'll use
threads. Nothew y htwo probave lems."
:-)
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
