2015-04-03 11:56 GMT+03:00 David Lang <da...@lang.hm>
>>> That's all well and good, but why do you loose more state when you do a
>>> HUP than when you do a full shutdown?
>>>
>>> I'm not even talking about restoring state after the HUP, I'm talking
>>> about the ability to output running counters.
>>>
>>> If I have a counter that's accumulating data that I output every hour
>>> (via
>>> a calendar command) and it's 1 sec before the end of the hour.
>>>
>>> If I do a full kill/restart I have the chance to output the data before I
>>> shutdown
>>>
>>> But if I do a HUP instead, that data is irrevokably lost.
>>>
>>> why should a full kill be more data friendly than a HUP?
>>>
>>> David Lang
>>>
>>>
>> hi David,
>> when we leave data storing on SEC_SHUTDOWN completely aside, and just
>> compare HUP and full restart as such, there are data items which are not
>> lost at HUP. Since the user can set up his custom Perl data structures
>> from
>> perlfunc patterns, but also with 'lcall', 'eval' and other such actions,
>> these data structures are not cleared. Since custom perl hashes, arrays
>> and
>> variables are not standard sec items and might have special semantics,
>> resetting them automatically is not a good idea, and futhermore, the user
>> can clear them easily on the reception of sec_restart event. So if you
>> keep
>> the counters in a perl hash/array, they will survive HUP.
>>
>
> ahh, I didn't realize this. I assumed that in clearing everything it would
> clear the entire namespace.
>
>
I also had a look at the official documentation and realized that this
aspect should be explicitly mentioned. That's another thing to fix in the
next version, apart from few other documentation improvements.
> But if someone was using the report functionality, that would be cleared,
> and giving them a chance to do something with the data first is a good idea.
>
> However, I do see your point that SEC_SHUTDOWN and SEC_STARTUP events
>> allow
>> to save and restore state when shutting down a process and starting a new
>> one, while SEC_RESTART alone does not allow for the same functionality
>> with
>> HUP. I suppose we could add another synthetic event like
>> SEC_PENDING_RESTART which is the last one seen before state gets dropped
>> on
>> HUP -- would that help to address your problem?
>>
>
> That's the type of thing I was looking for when I started. As John
> suggested, we shoudl probably have pending actions for the other signals as
> well while we are messing in the area
>
> David Lang
>
I will look into it and check the code how best to implement them.
kind regards,
risto
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
