Access Object From 2 Applications or Fix Scheduler

[Hendrik van Rooyen]

 "Robert Rawlins - Think Blue" <robert.rawlins at think......ia.co.uk> top posted:

>Also Hendrik,
>
>I should probably mention that the second application is a constant running
>application, it's nothing something that can just be 'started' by the first
>one, its running non-stop and just needs data passed into it regularly when
>the first application finds it.
>
>Application 1 Application 2
>Work with dict
>Work with dict
>Work with dict
>Work with dict
>New XML Found, Parse Into Dict --------------> Work with new dict
>Work with new dict
>Work with new dict
>Work with new dict
>
>You see how that works? Application 1 has a function that runs every minute
>and _may_ find a new xml file, if it does then I need it to parse that file
>into a list of dictionary and then pass that into application 2, which then
>starts using it :-)

ok - I see the difference - when you said schedule, I was thinking 
something like a cron job..

>
>Now we may be able to avoid this if there is some type of file watcher
>function available in python, my second application could then just watch
>the XML file and as soon as a new one is available parse it itself. Is that
>something you've heard of?

no to the tail like functionality - but then I am not an expert on what
is available

Now being a thread fanatic, I would do this sort of thing with a 
thread for scanning the world for the new XML, and if it finds 
a new thing, have it create the new dict.  (While it is doing this, 
the main thread is still using the old one).  Then, when the new 
dict is ready, I would put it on a Queue, which the main thread 
checks every time before it accesses the working dict, and then
if there is a new one, "overwrites" the old working one with the
new one by assigning the working dict name to the one from 
the queue:

try:
    workdict = dict_q.get()
except Queue.Empty:
    pass

where dict_q is the instance of Queue.Queue() that is used 
to link the two threads - create it in  __main__ before
starting the seeker thread so that it is visible to both the seeker
and worker that __main__ calls.   "  dict_q = Queue.Queue() "

After making the new dict, the seeker simply puts it on the queue
like this:

dict_q.put(new_dict)

Can't be simpler.

This has the advantage that the swap is made at a sensible point
in the worker thread, and the scheduling can be done in the 
seeker thread simply by calling time.sleep(60.0) at the start
of a while True loop. - it won't give you exactly sixty seconds 
to the millisecond, but this probably does not matter for something 
like this. - as long as you start using the new data "soon" its
probably all right.

For starting a thread, look at thread for basics and threading
for fancy, if you don't know already. I use thread because 
I am simple minded.

- Hendrik