Closed kseistrup closed 4 months ago
Hmm, to be honest, this feels like the wrong approach to this problem.
I usually don't like to implement features to solely compensate for other stuff being broken.
If any program hangs endlessly and this isn't expected behavior, it should just be fixed in that program.
If a program is expected to hang endlessly, but this isn't desired behavior, that program itself should add a --timeout
functionality. It shouldn't be up to the scheduler to handle this.
And as a bandaid, there already exists the timeout
command as you already pointed out.
Right now, I'm inclined to not get this implemented. But still, what exactly are some commands/scenarios that fail? Maybe I'm overlooking something.
I guess you're right that it should be added by the individual commands.
What I'm seeing at odd moments is networking programs that keep hanging (for reasons I'm incompetent to understand), something I have mitigated by prepending timeout $seconds
. I thought it would come in handy if the functionality was built into pueue, but seeing it from your point of view makes more sense.
I'll close the issue with this comment, I'm sorry if I have wasted your time.
Don't worry, no time wasted.
I'm just trying to triage feature requests to prevent feature creep and to keep the scope of pueue reasonable :)
It its default configuration pueue progresses throught the work queue one job at a time. What if a job takes forever? Then said job will block all subsequent jobs, won't it?
I can, of course, add jobs like so:
instead of:
but it would be nice if pueue could handle such things — either per job, or per queue.
Cheers.