Re: [mh] Is this the expected behaviour of process_item?

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]> 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
>

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users