"Robert Rawlins - Think Blue" <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
