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

Makes sense.

I wasn't trying to make work for you or anything, just thinking that if 
you were going to build something anyway it might be good to extend the 
current process_item code so it is available for everyone.

Thanks!


On 2021-02-18 1:28 p.m., 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]>> 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
>>>>>
>>>>
>>>
>>> <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/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
>>>
>>
>>
>> ________________________________________________________
>> 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