[FEATURE] - Several potential changes

[pcfreak30]

I believe this would need to be several PR's, but I want feedback on if they should be refactored upstream, the best approach?

v2...LumeWeb:gocron:expose_started_locker

Summary of changes:

• In executor.go:
  • Added a new channel jobOutUpdateLockRequest to the executor struct.
  • Modified the job execution process to send lock updates through this new channel.
  • Added code to signal the startedChan when a job begins execution.
• In job.go:
  • Added a new field lastLock to the job struct to store the most recent lock.
  • Added a startedChan channel to the job struct.
  • Implemented new methods for the Job interface:
    • Started(): Returns the startedChan.
    • Lock(): Returns the lastLock.
    • Context(): Returns the job's context.
• In scheduler.go:
  • Defined a new struct jobOutUpdateLockRequest for lock update requests.
  • Added a new channel jobOutUpdateLockRequest to handle these requests.
  • Implemented a new method jobOutUpdateLockRequest to process lock updates.
  • Modified the main event loop to handle lock update requests.
  • Updated the job initialization process to create the startedChan.

---

In summary

• Add to Job interface method to get the active context. I use this to abort a monitor thread if the job is canceled
• Add ability to get the active Lock if it exists which requires new channel comms between scheduler and executer. I use this to managing the lock directly outside cron library.
• Add a new startedChan and Started that flags when a task has begun but before the task function is called. I use this for a monitor to wait until the task is actually started.

@JohnRoesler

[JohnRoesler]

@pcfreak30 I can see the value in these features beyond your use. Happy to review a PR. The diff you have looks pretty straightforward, just some comments and such needed 👍

[pcfreak30]

One thing came to mind, would the startedChan be better off as some sort of callback for a "before start" as a job option?

as it stands I think it would need to be a go routine anyways to not block. but my case always uses it ATM.

Thoughts?

[JohnRoesler]

Good point, could do away with startedChan as you can just use the existing https://pkg.go.dev/github.com/go-co-op/gocron/v2#BeforeJobRuns event listener