From: Andrew Morton <akpm@digeo.com>
To: george anzinger <george@mvista.com>
Cc: torvalds@transmeta.com, cobra@compuserve.com,
linux-kernel@vger.kernel.org
Subject: Re: Runaway cron task on 2.5.63/4 bk?
Date: Mon, 10 Mar 2003 14:29:44 -0800 [thread overview]
Message-ID: <20030310142944.2dff3422.akpm@digeo.com> (raw)
In-Reply-To: <3E6D0FD5.2090707@mvista.com>
george anzinger <george@mvista.com> wrote:
>
> Linus Torvalds wrote:
> > On Mon, 10 Mar 2003, george anzinger wrote:
> >
> >>Lets consider this one on its own merits. What SHOULD sleep do when
> >>asked to sleep for MAX_INT number of jiffies or more, i.e. when
> >>jiffies overflows? My notion, above, it that it is clearly an error.
> >
> >
> > My suggestion (in order of preference):
> > - sleep the max amount, and then restart as if a signal had happened
>
> I think this will require a 64-bit expire in the timer_struct
> (actually it would not be treated as such, but the struct would still
> need the added bits). Is this ok?
>
> I will look at the problem in detail and see if there might be another
> way without the need of the added bits.
Is it not possible to just sit in a loop, sleeping for 0x7fffffff jiffies
on each iteration? (Until the final partial bit of course)
> Hm... I changed it to what it is to make it easier to track down
> problems in the test code... and this was user code. My thinking was
> that such large values are clear errors, and having the code "hang" in
> the sleep just hides the problem. But then, I NEVER make a system
> call without checking for errors.... And, I was making a LOT of sleep
> calls and wanted to know which one(s) were wrong.
If an app wants to sleep forever, calling
while (1)
sleep(MAX_INT);
seems like a reasonable approach. I'd expect quite a lot of applications
would be doing that.
next prev parent reply other threads:[~2003-03-10 22:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-09 7:30 Runaway cron task on 2.5.63/4 bk? Kevin Brosius
2003-03-09 8:08 ` Andrew Morton
2003-03-09 8:17 ` Andrew Morton
2003-03-09 16:28 ` [PATCH] " Todd Mokros
2003-03-10 19:42 ` george anzinger
2003-03-10 19:49 ` Linus Torvalds
2003-03-10 22:21 ` george anzinger
2003-03-10 22:29 ` Andrew Morton [this message]
2003-03-10 22:46 ` george anzinger
-- strict thread matches above, loose matches on Subject: below --
2003-03-10 23:05 Felipe Alfaro Solana
2003-03-10 23:33 ` Linus Torvalds
2003-03-11 10:20 ` george anzinger
2003-03-11 22:44 ` Andrew Morton
2003-03-11 23:02 ` Linus Torvalds
2003-03-11 23:09 ` Andrew Morton
2003-03-11 23:18 ` Linus Torvalds
2003-03-11 23:34 ` Andrew Morton
2003-03-11 23:46 ` george anzinger
2003-03-11 23:46 ` Linus Torvalds
2003-03-12 1:55 ` Jamie Lokier
2003-03-12 12:04 ` Denis Vlasenko
2003-03-11 23:35 ` george anzinger
2003-03-12 0:48 ` Matti Aarnio
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=20030310142944.2dff3422.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=cobra@compuserve.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.