Hi!
Please note the _timeout_ is set to 2008-08-25 since we don't have
much time left anymore, after that point the code will move to a
Mercurial tree for final review and integration.
Here comes round "two" of the preliminary code review for the first
update of the ksh93 integration proje
On 02/28/08 16:12, Garrett D'Amore wrote:
I don't believe that new threads are created, but there are
architecturally no guarantees that one invocation of a timeout function
run on the same thread as another. And on an SMP system, it is entirely
possible for two timeout functions to run at
Mladen Nikitovic wrote:
> Hi,
>
> I'm wondering about how timeout actually works in practice. I have an
> implementation of a kernel-module and it registers one of it's functions via
> timeout.
>
> The question is whether each invocation of that callout function generates a
> new thread or if
Hi,
I'm wondering about how timeout actually works in practice. I have an
implementation of a kernel-module and it registers one of it's functions via
timeout.
The question is whether each invocation of that callout function generates a
new thread or if is simply a function call?
I have a
On 29/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
No, and I mis-stated the above restriction. The restriction should
apply to mutexes held _across_ cv_wait. The mutex passed as an argument
to cv_wait is dropped by cv_wait, and not held during the sleep call, so
it can be acquired to do c
Paul Durrant wrote:
On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it
safely.)
Paul Durrant wrote:
On 29/05/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to d
Paul Durrant wrote:
On 29/05/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to d
On 29/05/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to do that
>> safely, but
Paul Durrant wrote:
On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it
safely.)
On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it safely.)
I was not aware of t
[EMAIL PROTECTED] wrote:
As my understand, cv_wait and its brethren could be called from a
interrupt context, including a soft interrupt context.
For this reason, when people read the timeout(9F), he will think since
timeout handler's context is considered as a soft interrupt context, it
wil
>As my understand, cv_wait and its brethren could be called from a
>interrupt context, including a soft interrupt context.
>For this reason, when people read the timeout(9F), he will think since
>timeout handler's context is considered as a soft interrupt context, it
>will be safe if we called
[EMAIL PROTECTED] wrote:
Garrett D'Amore wrote:
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in inter
>Garrett D'Amore wrote:
>> Thomas De Schampheleire wrote:
>>> Hi,
>>>
>>> The timeout(9F) manpage says:
>>>
>>> "The function called by timeout() must adhere to the same
>>> restrictions as a driver soft interrupt handler.
>>>
>>> The function called by timeout() is run in interrupt co
Garrett D'Amore wrote:
Oliver Yang wrote:
Garrett D'Amore wrote:
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in
Oliver Yang wrote:
Garrett D'Amore wrote:
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in interrupt context
a
Garrett D'Amore wrote:
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in interrupt context
and must not sleep or
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in interrupt context
and must not sleep or call other functions th
>Hi,
>
>The timeout(9F) manpage says:
>
>"The function called by timeout() must adhere to the same
> restrictions as a driver soft interrupt handler.
>
> The function called by timeout() is run in interrupt context
> and must not sleep or call other functions that might sleep."
>
>
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in interrupt context
and must not sleep or call other functions that might sleep."
Does this mean
21 matches
Mail list logo
