On 5 October 2016 at 18:26, Ted Unangst wrote:
> Christiano F. Haesbaert wrote:
>> There is another bug, the thread runs outside of IPL_SOFTCLOCK, the
>> interrupt handler already runs at IPL_SOFTCLOCK so it did not need to raise
>> it, but the thread does.
>>
>> The mutex is not enough as it will
Christiano F. Haesbaert wrote:
> There is another bug, the thread runs outside of IPL_SOFTCLOCK, the
> interrupt handler already runs at IPL_SOFTCLOCK so it did not need to raise
> it, but the thread does.
>
> The mutex is not enough as it will drop before running the handler, this
> can cause int
Am Montag, 26. September 2016 schrieb David Gwynne :
>
> > On 26 Sep 2016, at 13:36, Ted Unangst > wrote:
> >
> > David Gwynne wrote:
> >> +mtx_enter(&timeout_mutex);
> >> +while (!CIRCQ_EMPTY(&timeout_proc)) {
> >> +to = timeout_from_circq(CIRCQ_
> FIR
> On 26 Sep 2016, at 13:36, Ted Unangst wrote:
>
> David Gwynne wrote:
>> +mtx_enter(&timeout_mutex);
>> +while (!CIRCQ_EMPTY(&timeout_proc)) {
>> +to = timeout_from_circq(CIRCQ_FIRST(&timeout_proc));
>> +CIRCQ_REMOVE(&to->to_list);
David Gwynne wrote:
> + mtx_enter(&timeout_mutex);
> + while (!CIRCQ_EMPTY(&timeout_proc)) {
> + to = timeout_from_circq(CIRCQ_FIRST(&timeout_proc));
> + CIRCQ_REMOVE(&to->to_list);
leave();
> + timeout_run(
On Sat, Sep 24, 2016 at 12:20:02PM +0200, Christiano F. Haesbaert wrote:
> Am Samstag, 24. September 2016 schrieb David Gwynne :
>
> > On Fri, Sep 23, 2016 at 10:16:34PM -0700, Philip Guenther wrote:
> > > On Fri, 23 Sep 2016, Christiano F. Haesbaert wrote:
> > > ...
> > > > The diff as it is will
Am Samstag, 24. September 2016 schrieb David Gwynne :
> On Fri, Sep 23, 2016 at 10:16:34PM -0700, Philip Guenther wrote:
> > On Fri, 23 Sep 2016, Christiano F. Haesbaert wrote:
> > ...
> > > The diff as it is will deadlock against SCHED_LOCK.
> > > tsleep() calls sleep_setup(), which grabs SCHED_L
On Fri, Sep 23, 2016 at 10:16:34PM -0700, Philip Guenther wrote:
> On Fri, 23 Sep 2016, Christiano F. Haesbaert wrote:
> ...
> > The diff as it is will deadlock against SCHED_LOCK.
> > tsleep() calls sleep_setup(), which grabs SCHED_LOCK,
> > Then sleep_setup_timeout() will grab timeout_mutex in ti
On Fri, 23 Sep 2016, Christiano F. Haesbaert wrote:
...
> The diff as it is will deadlock against SCHED_LOCK.
> tsleep() calls sleep_setup(), which grabs SCHED_LOCK,
> Then sleep_setup_timeout() will grab timeout_mutex in timeout_add()
>
> On softclock() you have the opposite:
> Grabs timeout_mute
Am Mittwoch, 21. September 2016 schrieb Martin Pieuchot :
> On 21/09/16(Wed) 16:29, David Gwynne wrote:
> > [...]
> > the point i was trying to make was that the existing stuff (tasks,
> timeouts) can be used together to get the effect we want. my point was very
> poorly made though.
> >
> > i thi
On 21/09/16(Wed) 16:29, David Gwynne wrote:
> [...]
> the point i was trying to make was that the existing stuff (tasks, timeouts)
> can be used together to get the effect we want. my point was very poorly made
> though.
>
> i think your point is that you can make a clever change to timeouts and
> On 19 Sep 2016, at 20:28, Mike Belopuhov wrote:
>
> On 19 September 2016 at 11:06, Martin Pieuchot wrote:
>> On 19/09/16(Mon) 13:47, David Gwynne wrote:
>>> [...]
>>> id rather not grow the timeout (or task for that matter) apis just
>>> yet. theyre nice and straightforward to read and unders
On 15/09/16(Thu) 16:29, Martin Pieuchot wrote:
> After discussing with a few people about a new "timed task" API I came
> to the conclusion that mixing timeouts and tasks will result in:
>
> - always including a 'struct timeout' in a 'struct task', or the other
> the way around
> or
>
>
> Date: Mon, 19 Sep 2016 13:47:25 +1000
> From: David Gwynne
>
> On Fri, Sep 16, 2016 at 04:58:39PM +0200, Mark Kettenis wrote:
> > > Date: Thu, 15 Sep 2016 16:29:45 +0200
> > > From: Martin Pieuchot
> > >
> > > After discussing with a few people about a new "timed task" API I came
> > > to the
On Thu, Sep 15, 2016 at 04:29:45PM +0200, Martin Pieuchot wrote:
> After discussing with a few people about a new "timed task" API I came
> to the conclusion that mixing timeouts and tasks will result in:
>
> - always including a 'struct timeout' in a 'struct task', or the other
> the way ar
On 19 September 2016 at 11:06, Martin Pieuchot wrote:
> On 19/09/16(Mon) 13:47, David Gwynne wrote:
>> [...]
>> id rather not grow the timeout (or task for that matter) apis just
>> yet. theyre nice and straightforward to read and understand so far.
>
> So better introduce a new API, right?
>
>> f
On 19/09/16(Mon) 13:47, David Gwynne wrote:
> [...]
> id rather not grow the timeout (or task for that matter) apis just
> yet. theyre nice and straightforward to read and understand so far.
So better introduce a new API, right?
> for this specific problem can we do a specific fix for it? the di
On Fri, Sep 16, 2016 at 04:58:39PM +0200, Mark Kettenis wrote:
> > Date: Thu, 15 Sep 2016 16:29:45 +0200
> > From: Martin Pieuchot
> >
> > After discussing with a few people about a new "timed task" API I came
> > to the conclusion that mixing timeouts and tasks will result in:
> >
> > - alway
> Date: Thu, 15 Sep 2016 16:29:45 +0200
> From: Martin Pieuchot
>
> After discussing with a few people about a new "timed task" API I came
> to the conclusion that mixing timeouts and tasks will result in:
>
> - always including a 'struct timeout' in a 'struct task', or the other
> the way
> Date: Fri, 16 Sep 2016 16:03:50 +0200
> From: Vincent Gross
>
> On Thu, 15 Sep 2016 16:29:45 +0200
> Martin Pieuchot wrote:
>
> > After discussing with a few people about a new "timed task" API I came
> > to the conclusion that mixing timeouts and tasks will result in:
> >
> > - always inc
On Thu, 15 Sep 2016 16:29:45 +0200
Martin Pieuchot wrote:
> After discussing with a few people about a new "timed task" API I came
> to the conclusion that mixing timeouts and tasks will result in:
>
> - always including a 'struct timeout' in a 'struct task', or the
> other the way around
> or
21 matches
Mail list logo
