public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: "J. Roeleveld" <joost@antarean.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Recommendations for scheduler
Date: Sun, 03 Aug 2014 15:36:50 +0200	[thread overview]
Message-ID: <7486488.GXbi5se7ee@andromeda> (raw)
In-Reply-To: <slrnlts9md.e62.martin@lounge.imp.fu-berlin.de>

On Sunday, August 03, 2014 12:10:49 PM Martin Vaeth wrote:
> J. Roeleveld <joost@antarean.org> wrote:
> > A useful addition to your schedule-tool would be to store the
> > scripts in a way that makes editing simpler
> 
> Since it is an arbitrary script in an arbitrary language,
> I think this is not in the scope of this project to do this.
> In most cases I used it so far, 1-2 more or less complex lines
> (maybe a few more if they would not be complex)
> in an interactive zsh were enough, and these are very simple
> enough to edit in zsh, i.e. I even did not write any script "file"
> in the classical sense.
> 
> > I might be mistaken, but I think the server keeps the entire
> > queue in-memory and when the process dies, the status is lost?
> 
> Yes, the server process must not die.
> 
> If it dies, not only the queue is lost but also the waiting processes
> (that is: queued but not yet started) cannot be reached anymore:
> These waiting processes do not have their own TCP socket but just
> keep their established connection with the server's socket until
> the server tells them through this connection to start or to cancel;
> if this connection gets lost, the waiting processes die:
> What else could they do, reasonably?
> 
> The already started processes have a unique ID (into which the
> server's process is encoded): They reestablish the connection to report
> the exit status according to this ID. If the server is stopped,
> they cannot report this status, of course, and moreover,
> a new server does not know their IDs either and thus will ignore these
> "status reports".
> 
> Maybe this "protocol" is not the most clever solution, but it is
> one which could be implemented without lots of overhead:
> Mainly, I was up to a "quick" solution which is working good enough
> for me: If the server has no bugs, why should it die?
> Moreover, if the server dies for some strange reasons, it is probably
> safer to re-queue the jobs again, anyway.

With the kind of schedules I am working with (and I believe Alan will also end 
up with), restarting the whole process from the start can lead to issues.
Finding out how far the process got before the service crashed can become 
rather complex.

--
Joost


  reply	other threads:[~2014-08-03 13:37 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-01 17:32 [gentoo-user] Recommendations for scheduler Alan McKinnon
2014-08-01 17:49 ` Сергей
2014-08-01 17:50   ` Сергей
2014-08-01 19:10     ` Alan McKinnon
2014-08-03  9:27       ` Bruce Schultz
2014-08-03 12:08         ` Alan McKinnon
2014-08-04  3:07           ` Bruce Schultz
2014-08-01 18:17 ` [gentoo-user] " James
2014-08-01 19:19   ` Alan McKinnon
2014-08-01 19:35     ` covici
2014-08-02  9:18       ` Alan McKinnon
2014-08-02 13:34         ` J. Roeleveld
2014-08-01 21:17   ` J. Roeleveld
2014-08-01 21:02 ` Martin Vaeth
2014-08-01 21:22   ` J. Roeleveld
2014-08-01 22:06     ` Martin Vaeth
2014-08-02  9:27   ` Alan McKinnon
2014-08-01 21:13 ` [gentoo-user] " J. Roeleveld
2014-08-02  9:33   ` Alan McKinnon
2014-08-02 13:31     ` J. Roeleveld
2014-08-02 14:03       ` Alan McKinnon
2014-08-02 16:53         ` [gentoo-user] " James
2014-08-03  7:23           ` Joost Roeleveld
2014-08-03 12:16             ` Alan McKinnon
2014-08-03 13:33               ` J. Roeleveld
2014-08-05 19:57             ` James
2014-08-05 20:43               ` J. Roeleveld
2014-08-05 21:29                 ` Alan McKinnon
2014-08-06  8:29                 ` Peter Humphrey
2014-08-06 10:26                   ` J. Roeleveld
2014-08-03  7:50       ` Martin Vaeth
2014-08-03  8:06         ` J. Roeleveld
2014-08-03 12:10           ` Martin Vaeth
2014-08-03 13:36             ` J. Roeleveld [this message]
2014-08-03 20:04               ` Alan McKinnon
2014-08-03 20:23                 ` J. Roeleveld
2014-08-03 20:57                   ` Alan McKinnon
2014-08-03 21:10                     ` J. Roeleveld
2014-08-04  8:41               ` Martin Vaeth
2014-08-04  9:02                 ` J. Roeleveld
2014-08-04 10:11                   ` Martin Vaeth
2014-08-04 10:40                     ` J. Roeleveld
2014-08-04 13:31                       ` Martin Vaeth
2014-08-04 13:35                         ` Alan McKinnon
2014-08-04 19:46                           ` J. Roeleveld
2014-08-04 20:38                             ` Alan McKinnon
2014-08-05 11:42                               ` J. Roeleveld
2014-08-04 19:54                         ` J. Roeleveld
2014-08-05  6:33                           ` Martin Vaeth
2014-08-05 11:32                             ` J. Roeleveld
2014-08-08 23:21                               ` Martin Vaeth
2014-08-03 13:02     ` [gentoo-user] " Tanstaafl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7486488.GXbi5se7ee@andromeda \
    --to=joost@antarean.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox