New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: deferred / buffered saves #432

Closed
maimizuno opened this Issue Jul 23, 2017 · 1 comment

Comments

Projects
None yet
1 participant
@maimizuno

[Given:] there are two variables that control what time of day (and what part of the hour) daily saves occur.

[Proposal:] a variable to restrict saves (userfile & chanfile) to once a day for systems running on flash memory (such as on nano boards, like the Banana Pi and Raspberry Pi), where the number of saves is rather finite before memory failure. The request is: when a certain config variable is set, BUFFER or POSTPONE saves until the triggered time.

Example 1:
set restrict-save 300 ; # Only perform [buffered] save at 3 AM (or whenever)
Perform a save at 3AM [local time] only, if saves are pending.
Note: time must be "padded" to 4-digits internally
At the requested time, trigger by same method as BIND TIME (if time is passed due to "timer drift," execute as soon as bot is "caught-up"), then perform save/savechannels/backup/flushlogs* as required
Log entry [o]: userfile [or "chanfile" or "backup"] save buffered
If no saves are pending, then nothing should happened at the trigger-time (no "useless" saves)

  • = See "flushlogs" notes below

New functions: tcl-commands.doc
[savebuffered]
Returns: logical OR of the following values:
1 (save was buffered / not performed due to restriction),
2 (savechannels was not performed due to restriction)
4 (backup was not performed due to restriction)
8 (logfile writes were not performed due to restriction)
Sample code:
set buffer [savebuffered] ; # Can be run at any time to see current status
if { $buffer % 1 } { save is pending } ; # A check for buffered save
if { $buffer % 2 } { savechannels is pending } ; # A check for buffered savechannels
if { $buffer % 4 } { backup is pending } ; # A check for buffered backup
if { $buffer % 8 } { logfile writes are pending } ; # A check for buffered logs
Again, times must be "padded" to 4-digits internally

Example 2:
set restrict-save [list 0 600 1200 1800] ; # Perform saves only at these times
Same "rules" as Example 1
Again, times must be "padded" to 4-digits internally

Example 3:
set restrict-save -1 ; # Or "off" or "manual" -- do not perform any automatic / timed saves (rely on manual use of SAVE / SAVECHANNELS / BACKUP / FLUSHLOGS commands)

Example 4:
set restrict-save "" ; # Do not preform any automatic file writes AND DO NOT BUFFER ANY LOGFILE SAVES IN MEMORY
Same as example 3, except: do not save anything information in memory. This would prevent additional Eggdrop memory footprint. This would be a "forgetful" bot, relying solely on manual SAVE / SAVECHANNELS / BACKUP. This would be useful for a bot that doesn't log channels

Example 5:
if { ![info exists ::restrict-save] } { perform saves / logs as normal }
Commented-out: no buffering; perform all file writes as normal.

=====

All of the above options should also affect the writing of log files.
This =might= require a new command: FLUSHLOGS (push all logfile entries to disk)
FLUSHLOGS <"all" | "*" or #channel>: flush any and all matching log files

Of course, it would be smart for script coders to add a pre-die event to save if the bot is being shut-down. (As documented, this would not help during a KILL -9 or SEGV).

Appropriate caveats would need to be listed so users would know the risks of data not being saved [updated] regularly (i.e. newly added users, deleted users, changed user flags).

Triggeres to track when saves are needed: adduser / addbot, / remuser, chattr, setuser, dccsend (because it affects a user's FSTAT value); chanset / channel set

I realize that this setup will increase Eggdrop's memory footprint for logfiles; for SAVE/SAVECHANNEL/BACKUP, no additional memory would be used (other than boolean values to indicate which type of save is being "blocked" until the proper time).

@maimizuno

This comment has been minimized.

Show comment
Hide comment
@maimizuno

maimizuno Jul 30, 2018

issue reporter is code ID10t.

issue reporter is code ID10t.

@maimizuno maimizuno closed this Jul 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment