Re: [mh] Process_item_queue <more partly solved>
H Plato <[email protected]> Wed, 24 Feb 2021 10:16:48 -0700
| Newsgroups | gmane.comp.misc.misterhouse.user |
|---|---|
| Message-ID | <[email protected]> |
If you look at my raZberry code (around line 512), I use a multi-dimensional array in a hash to hold various attributes related to the process_item queue. Hopefully that might help a bit. For my moduled, it seemed to me that keeping a queue array as part of the process_item object was a simpler approach. It kept the data and methods encapsulated. > On Feb 24, 2021, at 9:32 AM, Giles Godart-Brown <[email protected]> wrote: > > I've made a lot of progress this week, this version still uses a single queue, but it sorts it by process_name and time and then runs ones with different names in parallel, so it appears like there is a queue for each process. > > It currently has a lot of debug prints and tests in it as I try to check all the edge cases (no guarantees that I've succeeded) . I will remove these if you think it worth creating a pull to incorporate it into MisterHouse Master. If so I'll need some help. > > I've still failed to be able to build a 3D hash array to include process with more than one command, so it only works for processes with a single command and throws an error if you try to queue a process with more than one. > > Giles > > On 20/02/2021 15:08, Giles Godart-Brown wrote: >> I've now fixed the problem with changes to the process item before it was removed from the queue. >> >> There are 2 limitations with this solution; >> >> 1) its a single FIFO, all process_items are executed in the order they arrive on the queue >> >> 2) I struggled with array references and arrays of arrays, so there is a limit to a single command process_item i.e. no add('program3 arguments', 'program4 arguments', ...). It simply runs the first command assigned to the process_item. >> >> I think this can be improved by adding a time_added_to_queue column and sorting the queue on process_name and time_added_to_queue. >> >> Then when it processes the queue instead of it just taking the top of the queue it takes the first entry for each process_name i.e. a sort of parallel queue. >> >> If I get some time over the weekend I'll see if I can implement this. >> >> I'm no expert on the innards of MisterHouse and how the modules work, so If you think it worthwhile I'd like some help turning this into a module for a future pull request. >> >> Thanks in anticipation >> >> Giles >> >> >> >> On 19/02/2021 19:17, Giles Godart-Brown wrote: >>> Attached is a first go at building a process_item_queue. >>> >>> Its a single queue, and I'm sure one queue per process_item would be better, but I've run out of talent :-) >>> >>> Giles >>> >>> On 18/02/2021 18:28, Giles Godart-Brown wrote: >>>> I was going to build it for myself, then if its good enough (?) and fulfils backwards compatibility I will add a pull >>>> >>>> G >>>> >>>> On 18/02/2021 17:25, Jeff Siddall via misterhouse-users wrote: >>>>> Giles, >>>>> >>>>> When you say "I'll build a queue" do you mean for your project or adding it onto process_items? As long as it was backwards compatible with the existing behavior of a process_item, it would be nice to add that onto the process_item so there is a standard way for anyone to push items onto a process_item queue instead of everyone implementing it their own way. >>>>> >>>>> Jeff >>>>> >>>>> >>>>> On 2021-02-18 11:47 a.m., Giles Godart-Brown wrote: >>>>>> >>>>>> Thanks H >>>>>> >>>>>> I'll build a queue and update the docs over the weekend >>>>>> >>>>>> Giles >>>>>> >>>>>> On 18/02/2021 14:24, H Plato wrote: >>>>>>> As far as I know that’s how it works, the process_item has a single thread. You can check if the process_item is still active by calling$p_longproc->done(), and then queuing the additional commands to an array. That’s how I’ve dealt with this in some of my modules >>>>>>> >>>>>>>> On Feb 18, 2021, at 1:22 AM, Giles Godart-Brown <[email protected] <mailto:[email protected]> <mailto:[email protected]> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> I use process_items to send messages and urls, occasionally (usually when I write bad code) I need to send a lot of emails in quick succession but MisterHouse kills any unfinished ones, rather than running them in parallel which is what I expected. To test this I built a minimum reproducible case below where it launches a process that simply sleeps for 5 seconds twice in succession. As you can see from the print log, he first one gets killed. >>>>>>>> >>>>>>>> Is this normal? >>>>>>>> >>>>>>>> Giles >>>>>>>> >>>>>>>> <mytest.pl> >>>>>>>> >>>>>>>> print_log( "Longproc run 1", "INFORMATIONAL", "p_longproc" ); >>>>>>>> start $p_longproc; >>>>>>>> print_log( "Longproc run 2", "INFORMATIONAL", "p_longproc" ); >>>>>>>> start $p_longproc; >>>>>>>> </mytest.pl> >>>>>>>> >>>>>>>> <longproc.sh> >>>>>>>> >>>>>>>> #!/bin/sh >>>>>>>> # shell to sleep >>>>>>>> echo longproc start 5 second sleep pid= $$ >>>>>>>> sleep 5 >>>>>>>> echo "longproc end" >>>>>>>> exit 0 >>>>>>>> </longproc.sh> >>>>>>>> >>>>>>>> <print.log> >>>>>>>> >>>>>>>> 18/02/2021 08:10:27 [p_longproc] INFO Longproc run 1 >>>>>>>> 18/02/2021 08:10:27 [p_longproc] INFO Longproc run 2 >>>>>>>> Warning, a previous 'start' on this process has not finished yet >>>>>>>> Killing unfinished process id 9380 cmd=//home/pi/mh/GGBcode/procs/longproc.sh >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> 18/02/2021 08:10:33 [p_longproc] longproc start 5 second sleep pid= 9381 >>>>>>>> 18/02/2021 08:10:33 [p_longproc] longproc end >>>>>>>> >>>>>>>> </print.log> >>>>>>>> >>>>>>>> ________________________________________________________ >>>>>>>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users <https://lists.sourceforge.net/lists/listinfo/misterhouse-users> >>>>>>>> >>>>>>> >>>>>> >>>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >>>>>> >>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>>>> >>>>>> >>>>>> ________________________________________________________ >>>>>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users <https://lists.sourceforge.net/lists/listinfo/misterhouse-users> >>>>>> >>>>> >>>>> >>>>> ________________________________________________________ >>>>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users <https://lists.sourceforge.net/lists/listinfo/misterhouse-users> >>>>> >>> >>> > <process_item_queue.pl><longproc.sh>________________________________________________________ > To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users > ________________________________________________________ To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users