On Wed, Aug 12, 2020 at 09:07:15PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Wed, 12 Aug 2020 12:38:39 +0300
> Vitaliy Makkoveev wrote:
> > We don't need to mark pppx(4) sessions because there is no special cases
> > for them. We just need to kill pppx(4) related "pr_timeout_sec != 0"
> >
Hi,
On Wed, 12 Aug 2020 12:38:39 +0300
Vitaliy Makkoveev wrote:
> We don't need to mark pppx(4) sessions because there is no special cases
> for them. We just need to kill pppx(4) related "pr_timeout_sec != 0"
> checks and call pipex_get_closed() by pppx_get_closed().
How do you implement that
On Wed, Aug 12, 2020 at 11:17:29AM +0900, YASUOKA Masahiko wrote:
> On Tue, 11 Aug 2020 23:06:45 +0300
> Vitaliy Makkoveev wrote:
> > We removed `pipex{in,out}q'. So now we can destroy pppac(4) session just
> > like we do in pppx(4) case. Also there is no reason to allow
> > pipex_timer() to
On Tue, 11 Aug 2020 23:06:45 +0300
Vitaliy Makkoveev wrote:
> We removed `pipex{in,out}q'. So now we can destroy pppac(4) session just
> like we do in pppx(4) case. Also there is no reason to allow
> pipex_timer() to destroy sessions - userland will do this by
> PIPEXDSESSION. This permit us to
On Wed, Aug 12, 2020 at 01:36:38AM +0900, YASUOKA Masahiko wrote:
>
> my diff is to make pppx(4) have the same "idle-timeout"
> functionality. I strongly think pppx(4) must have the same
> functionalities of pppac(4) because I don't see any reason to have
> any difference between pppx(4) and
On Wed, Aug 12, 2020 at 12:37:13AM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Mon, 10 Aug 2020 16:30:27 +0300
> Vitaliy Makkoveev wrote:
> > On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote:
> >> On Sun, 9 Aug 2020 20:03:50 +0300
> >> Vitaliy Makkoveev wrote:
> >> > On Sun, Aug
my diff is to make pppx(4) have the same "idle-timeout"
functionality. I strongly think pppx(4) must have the same
functionalities of pppac(4) because I don't see any reason to have
any difference between pppx(4) and pppac(4).
Your pseudo code is suggesting another thing. You would like to
Hi,
On Mon, 10 Aug 2020 16:30:27 +0300
Vitaliy Makkoveev wrote:
> On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote:
>> On Sun, 9 Aug 2020 20:03:50 +0300
>> Vitaliy Makkoveev wrote:
>> > On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote:
>> >> You propose to
> On 10 Aug 2020, at 19:53, Vitaliy Makkoveev wrote:
>
> We are doing all wrong :)
>
> We can just unlink pppx(4) related session from `pipex_session_list' if
> it's time expired. But since this unlinked session is still exists in
> pppx(4) layer we can access through pppx_get_closed()
We are doing all wrong :)
We can just unlink pppx(4) related session from `pipex_session_list' if
it's time expired. But since this unlinked session is still exists in
pppx(4) layer we can access through pppx_get_closed() without any
search. We should only add flag to session which identifies it
On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> Thank you for your review.
>
> On Sun, 9 Aug 2020 20:03:50 +0300
> Vitaliy Makkoveev wrote:
> > On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote:
> >> You propose to unlink pppx(4) related session which
Hi,
Thank you for your review.
On Sun, 9 Aug 2020 20:03:50 +0300
Vitaliy Makkoveev wrote:
> On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote:
>> You propose to unlink pppx(4) related session which reached timeout. I'm
>> ok with this direction. But I see no reason to rework
On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote:
> Hello Yasuoka.
>
> You propose to unlink pppx(4) related session which reached timeout. I'm
> ok with this direction. But I see no reason to rework _get_closed()
> routines.
>
> in pppac(4) case it's assumed what if session is
Hello Yasuoka.
You propose to unlink pppx(4) related session which reached timeout. I'm
ok with this direction. But I see no reason to rework _get_closed()
routines.
in pppac(4) case it's assumed what if session is not yet destroyed by
garbage collector, it will be destroyed while we performing
14 matches
Mail list logo
