[split] Impossible to place snap decisions on greeter while screen is unlocked

Is this not the same as bug #1325702?

Adding a unity-notifications task, as it might be involved in whatever solution we come up with.

This is different than the queued snap decision bug apparently. I'm looking at it.

So quick brain dump. This is due to the unity8-greeter process being SIGSTOPPED while not active, seemingly due to Mir lifecycles. While sleeping, the snap decision Notify call apparently gets "stuck" in the dbus pipe and still delivered afterward, even if the source of the notification does a close() on it.

But the unity8 shell does *not* get SIGSTOPPED when inactive. And for that matter, unity8-greeter doesn't always have this problem either, which is why this bug isn't 100% reproducable.

So some piece of logic is keeping the unity8 shell active. The greeter should probably do the same thing.

Alternately, we could figure out why the Notify call is stuck in the dbus socket and stop that from happening. But the above is also useful.

On 09.06.2014 22:08, Michael Terry wrote:
> So quick brain dump. This is due to the unity8-greeter process being
> SIGSTOPPED while not active, seemingly due to Mir lifecycles. While
> sleeping, the snap decision Notify call apparently gets "stuck" in the
> dbus pipe and still delivered afterward, even if the source of the
> notification does a close() on it.

Huh!? Are you sure it gets stopped? There's nothing that you can
describe "Mir lifecycle"... It's unity-mir that handles lifecycle. The
only thing that *could* happen, but shouldn't any more, would be blocked
rendering when greeter inactive, causing events to be queued (but
non-blocking eglSwapBuffers handled exactly that). We just need to make
sure the correct expose events are delivered to unity8 and
unity8-greeter, as applicable.

True, it may not be SIGSTOPPED, but just blocked on render. I'm basing my guess on a test I ran where I disabled the lifecycle code in USC and it started working again. But maybe that was coincidence. Or maybe that was related to render blocking instead of SIGSTOP.

I'm still investigating

OK, got it in a state and tested via "ps aux" whether it was actually SIGSTOPped and seems like no. So I'm guessing some sort of render block... non-blocking mode was supposed to fix that, but perhaps in conjunction with Mir lifecycles, something still blocks inactive sessions.It only

On 10.06.2014 18:54, Michael Terry wrote:
> OK, got it in a state and tested via "ps aux" whether it was actually
> SIGSTOPped and seems like no. So I'm guessing some sort of render
> block... non-blocking mode was supposed to fix that, but perhaps in
> conjunction with Mir lifecycles, something still blocks inactive
> sessions.It only

It only...?

In any case, I'm not aware of anything that could be dubbed "Mir
lifecycles"... Blocked rendering would be the only thing I could explain
this with.

I'm not sure what the "It only" fragment was supposed to be. :)

Sure, you know Mir lifecycles. The "about_to_suspend" and "resume" lifecycle events that a mirserver sends to its mirclients. Usually used between unity8 and apps, but also technically used between USC and child sessions.