From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Nish Aravamudan <nish.aravamudan@gmail.com>
Cc: Willem Riede <osst@riede.org>,
kernel-janitors@lists.osdl.org, osst-users@lists.sourceforge.net,
linux-scsi@vger.kernel.org
Subject: Re: [Kernel-janitors] [PATCH] Re: no set_current_state() before
Date: Tue, 13 Jul 2004 23:56:41 +0000 [thread overview]
Message-ID: <40F476B9.4090101@us.ibm.com> (raw)
In-Reply-To: <29495f1d04071316362e782433@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]
Nish Aravamudan wrote:
> On Tue, 13 Jul 2004 23:07:32 +0000, Willem Riede <osst@riede.org> wrote:
>
>>
>>On 07/13/2004 01:40:54 PM, Nishanth Aravamudan wrote:
>
>
> <snip>
>
>>>If someone could tell me which state (TASK_INTERRUPTIBLE or
>>>TASK_UNINTERRUPTIBLE) is desired, I can fix this and perhaps replace the
>>>calls with msleep().
>>
>>You're right, there is a set_current_state(TASK_INTERRUPTIBLE) missing.
>>I don't know why we would want to change to use msleep() though.
>
>
> <snip>
>
> The main reason I see for using msleep() instead is if the task should
> sleep for at least 100 ms. Using TASK_INTERRUPTIBLE (or really
> anything other than msleep()) is not guaranteed to sleep as long as
> requested. If that's ok / desired, then I won't convert it, of course.
To be clear, the 100 ms I mention above is specific to this example. In
general, if the time you want to sleep (and you really want to *sleep*
for that time) is measureable in msecs, then msleep() is the way to go.
-Nish
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Nish Aravamudan <nish.aravamudan@gmail.com>
Cc: Willem Riede <osst@riede.org>,
kernel-janitors@lists.osdl.org, osst-users@lists.sourceforge.net,
linux-scsi@vger.kernel.org
Subject: Re: [Kernel-janitors] [PATCH] Re: no set_current_state() before schedule_timeout() (OSST)
Date: Tue, 13 Jul 2004 23:56:41 +0000 [thread overview]
Message-ID: <40F476B9.4090101@us.ibm.com> (raw)
In-Reply-To: <29495f1d04071316362e782433@mail.gmail.com>
Nish Aravamudan wrote:
> On Tue, 13 Jul 2004 23:07:32 +0000, Willem Riede <osst@riede.org> wrote:
>
>>
>>On 07/13/2004 01:40:54 PM, Nishanth Aravamudan wrote:
>
>
> <snip>
>
>>>If someone could tell me which state (TASK_INTERRUPTIBLE or
>>>TASK_UNINTERRUPTIBLE) is desired, I can fix this and perhaps replace the
>>>calls with msleep().
>>
>>You're right, there is a set_current_state(TASK_INTERRUPTIBLE) missing.
>>I don't know why we would want to change to use msleep() though.
>
>
> <snip>
>
> The main reason I see for using msleep() instead is if the task should
> sleep for at least 100 ms. Using TASK_INTERRUPTIBLE (or really
> anything other than msleep()) is not guaranteed to sleep as long as
> requested. If that's ok / desired, then I won't convert it, of course.
To be clear, the 100 ms I mention above is specific to this example. In
general, if the time you want to sleep (and you really want to *sleep*
for that time) is measureable in msecs, then msleep() is the way to go.
-Nish
next prev parent reply other threads:[~2004-07-13 23:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 16:44 [Kernel-janitors] no set_current_state() before schedule_timeout() Nishanth Aravamudan
2004-07-13 17:10 ` Nishanth Aravamudan
2004-07-13 17:16 ` Nishanth Aravamudan
2004-07-13 17:20 ` Nishanth Aravamudan
2004-07-13 17:28 ` Nishanth Aravamudan
2004-07-13 17:31 ` Nishanth Aravamudan
2004-07-13 17:34 ` Nishanth Aravamudan
2004-07-13 17:34 ` no set_current_state() before schedule_timeout() (53C700) Nishanth Aravamudan
2004-07-13 17:36 ` [Kernel-janitors] no set_current_state() before schedule_timeout() Nishanth Aravamudan
2004-07-13 17:40 ` Nishanth Aravamudan
2004-07-13 17:40 ` no set_current_state() before schedule_timeout() (OSST) Nishanth Aravamudan
2004-07-13 22:27 ` [Kernel-janitors] [PATCH] Re: no set_current_state() before Willem Riede
2004-07-13 23:07 ` [PATCH] Re: no set_current_state() before schedule_timeout() (OSST) Willem Riede
2004-07-13 23:36 ` [Kernel-janitors] [PATCH] Re: no set_current_state() before Nish Aravamudan
2004-07-13 23:36 ` [Kernel-janitors] [PATCH] Re: no set_current_state() before schedule_timeout() (OSST) Nish Aravamudan
2004-07-13 23:56 ` Nishanth Aravamudan [this message]
2004-07-13 23:56 ` Nishanth Aravamudan
2004-07-13 23:59 ` [Kernel-janitors] [PATCH] Re: no set_current_state() before Willem Riede
2004-07-14 0:45 ` [Kernel-janitors] [PATCH] Re: no set_current_state() before schedule_timeout() (OSST) Willem Riede
2004-07-13 17:43 ` [Kernel-janitors] no set_current_state() before schedule_timeout() Nishanth Aravamudan
2004-07-13 17:43 ` no set_current_state() before schedule_timeout() (QLA1280) Nishanth Aravamudan
2004-07-13 17:45 ` [Kernel-janitors] no set_current_state() before schedule_timeout() Nishanth Aravamudan
2004-07-13 17:45 ` no set_current_state() before schedule_timeout() (scsi_lib) Nishanth Aravamudan
2004-07-13 17:51 ` [Kernel-janitors] no set_current_state() before schedule_timeout() Nishanth Aravamudan
2004-07-13 17:52 ` Nishanth Aravamudan
2004-07-13 17:54 ` Nishanth Aravamudan
2004-07-13 17:57 ` Nishanth Aravamudan
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=40F476B9.4090101@us.ibm.com \
--to=nacc@us.ibm.com \
--cc=kernel-janitors@lists.osdl.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nish.aravamudan@gmail.com \
--cc=osst-users@lists.sourceforge.net \
--cc=osst@riede.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 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.