On 22.02.2018 09:49, Tanu Kaskinen wrote: > On Thu, 2018-02-22 at 09:26 +0100, Georg Chini wrote: >> On 21.02.2018 21:02, Georg Chini wrote: >>> On 21.02.2018 20:15, Raman Shishniou wrote: >>>> On 02/21/2018 09:41 PM, Raman Shuishniou wrote: >>>>> 21.02.2018 20:07, Georg Chini пиÑ?еÑ?: >>>>>> Maybe you misunderstood me. What I mean, is that the pipe can be >>>>>> opened for writing as long as we are suspended. So it open when >>>>>> we see that the source is suspended or when we auto suspend. Close >>>>>> it as soon as the source gets unsuspended. This will avoid POLLHUP >>>>>> during suspend completely. While auto suspended, we additionally have >>>>>> to listen for POLLIN. >>>>>> This way we can only get POLLHUP (or POLLIN with no data) when the >>>>>> source is running. >>>>>> >>>>> I think I understand. We need to keep our writer opened while >>>>> transition >>>>> from autosuspended to opened state and just set events = 0. >>> Exactly. I was also thinking about how to decide if data can be discarded >>> or needs to be posted. On resume, the SET_STATE handler could set a >>> just_unsuspended flag and when we know auto suspend is the only >>> suspend cause, we can additionally set a resume_from_auto_suspend >>> flag when we send the unsuspend message. In the thread function we >>> could then check if >>> >>> just_unsuspended && resume_from_autosuspend -> post pending data, >>> reset flags >>> just_unsuspended && !resume_from_auto_suspend -> discard data, reset >>> flags >>> !just_unsuspended -> post data >>> >>> But that's only an idea. >> It's even simpler, because the old and new suspend cause are available >> in the >> SET_STATE handler (or in the set_state_in_io_thread() callback). So >> there we can >> do: >> if (old_cause == AUTO_SUSPEND && new_cause == 0) -> >> resume_from_auto_suspend = true >> else if (old_caue != 0 && new_cause == 0) -> resume_from_user_suspend = true >> >> BTW, maybe we should have a new suspend cause for that. Currently, >> the best suspend cause we could use is PA_SUSPEND_UNAVAILABLE. >> In the future however, it is planned, that streams get rescued when >> the suspend cause is PA_SUSPEND_UNAVAILABLE and I guess that is >> not what you want in your case. > IIRC, we agreed that the stream rescuing will be done based on port > availability, so the suspend state and cause will not be considered. OK, my understanding was it would work like this: No port -> set SUSPEND_UNAVAILABLE If SUSPEND_UNAVAILABLE gets set -> rescue stream. This would make it somewhat more generic and not alsa specific. But I am OK with using the port availability directly. > > FWIW, I'm OK with using any of UNAVAILABLE, APPLICATION or some new > suspend cause in the pipe source. I'd like to some day change the > suspend system that the causes are identified by strings (in a hashmap) > instead of enumeration values so that we don't have to pretend having > some generic suspend causes when in reality each of them tends to be > very specific to a particular piece of code. > I'd say the best fit in that case is PA_SUSPEND_UNAVAILABLE.
