On Thu, Sep 20, 2018 at 06:14:11PM +0200, Markus Armbruster wrote:
> Wolfgang Bumiller writes:
>
> > On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> >> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> >>
> >> > Either way, spawning the iothread on demand can still
Wolfgang Bumiller writes:
> On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
>> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>>
>> > Either way, spawning the iothread on demand can still make sense, as
>> > does updating the check in resume()/suspend().
>>
>> Yep.
Wolfgang Bumiller writes:
> On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
>> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>> > On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
>> > > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
>> >
On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>
> > Either way, spawning the iothread on demand can still make sense, as
> > does updating the check in resume()/suspend().
>
> Yep.
Running into an issue with that ap
On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> > On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> > > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > > > On Wed, Sep 19, 2018 at 03:36
On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > > On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> > > > Peter Xu writes:
>
On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> > > Peter Xu writes:
> > > > Indeed. So we have these ordering constraints:
> > > >
> > > > ini
On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> > Peter Xu writes:
> >
> > > On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote:
> > >> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbrus
On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote:
> >> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
> >> > From: Peter Xu
> >> >
> >> > Before this patch, monitor f
Peter Xu writes:
> On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote:
>> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
>> > From: Peter Xu
>> >
>> > Before this patch, monitor fd helpers might be called even earlier than
>> > monitor_init_globals(). This ca
On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote:
> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
> > From: Peter Xu
> >
> > Before this patch, monitor fd helpers might be called even earlier than
> > monitor_init_globals(). This can be problematic.
> >
> >
On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
> From: Peter Xu
>
> Before this patch, monitor fd helpers might be called even earlier than
> monitor_init_globals(). This can be problematic.
>
> After previous work, now monitor_init_globals() does not depend on
> accelerator
From: Peter Xu
Before this patch, monitor fd helpers might be called even earlier than
monitor_init_globals(). This can be problematic.
After previous work, now monitor_init_globals() does not depend on
accelerator initialization any more. Call it earlier (before CLI
parsing; that's where the
13 matches
Mail list logo