[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Filter design for nsmux

From: Sergiu Ivanov
Subject: Re: Filter design for nsmux
Date: Thu, 23 Apr 2009 06:13:27 -0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

<olafBuddenhagen@gmx.net> writes:
> On Sun, Feb 22, 2009 at 08:56:50PM +0200, Sergiu Ivanov wrote:
>> On Wed, Feb 18, 2009 at 10:01 PM,  <olafBuddenhagen@gmx.net> wrote:
>> > As I already pointed out, sooner or later we will problably need
>> > some framework to conflate simimlar translator instances in a single
>> > process -- while dynamic translators are likely to make the problem
>> > evident in many cases, the problem itself is not specific to them...
>> Indeed, I have also thought about reusing a single translator instance
>> for similar requests this week, and this does solve the
>> number-of-processes issue.
>> However, I remember you pointing out that some of the translators may
>> be incapable of dealing with multiple clients... Do we forget about
>> such possibility or shall we think about this further?..
> I said running multiple translator instances in one process, not sharing
> one translator instance among clients... That's quite a different thing
> :-)

Hm, that's really a different thing... I understand that this question
will be offtopic, but I'll still ask you: do your words imply that we
will somehow run multiple processes within a single process?..

> Anyways, the purpose of my remark was to remind you that -- as I
> explained before -- this is really an orthogonal issue, and we should
> not consider it as part of the nsmux design.

OK, this is reasonable.

>> >> Could we possibly define a new RPC (a bit frightening for me,
>> >> unfourtunately) to make the shadow nodes yield the real port? That
>> >> is, when the client should invoke this RPC on the port it obtains
>> >> from the filter, they should get the port directly, not involving
>> >> shadow nodes?
>> >
>> > That is actually the solution I was considering. I don't really like
>> > it, because this way nsmux is not transparent to the filter: the
>> > filter needs to be aware that it is run by nsmux, and handle it
>> > specially. I can't think of any other approach, though.
>> >
>> > (At least this way nsmux/the shadow nodes would be transparent again
>> > once the filter is done.)
>> By saying ``transparency'' do you mean that at the invocation of this
>> new special RPC, nsmux will give to the client a proxy of the
>> translator port directly, without employing shadow nodes?
> I mean that the filter invokes the special RPC to obtain a version of
> the node without surplus shadows, returning this to the actual client.
> Thus the procedure is not transparent to the filter -- it needs to know
> that nsmux is involved and invoke the special RPC -- but it is
> transparent to the actual client: it gets a "clean" node, devoid of
> undesired shadows, just as if they never existed.

Aha, I see. It means I've understood this thing correctly.

Another question now (probably, I'm repeating myself already...): how
problematic is that the filter should know about nsmux? After all, the
filter's main real use case is running in a dynamic translator stack. I
understand that having the filter capable of running as a normal
translator would be a nice option, but I fail to find the absence of
this feature a very bad thing.

>> > My major concern here is deciding whether to add the new RPC(s) to
>> > the existing interfaces, or create a completely new one...
>> I'm not sure I can fully comprehend the implications of this
>> statement... Could you please explain further?..
> RPCs don't exist on their own: they are always part of some interface.
> The RPC for getting the underlying node logically would belong to the
> file interface (fs.defs) -- we would have to modify the existing
> interface, and adapt all users. (AIUI this shouldn't actually be too
> hard: just add a new stub server function to all the translator
> libraries.)

Aha, I see. I must acknowledge, I used to think that adapting all users
would be a much more difficult action.

> The alternative is creating a new interface just for this special call.
> We wouldn't need to touch existing interfaces; but it would be rather
> unelegant...

I am somehow more inclined to creating a new special interface for
nsmux... Could please point out the reasons why you consider this
solution rather unelegant?

>> [...] there is no already existing
>> RPC for going one translation layer lower.
> My point is that traversing bottom-to-top isn't any more natural, as it
> requires obtaining the untranslated node at the bottom of the stack, and
> there is no existing RPC for that either.

Hm, I think I cannot understand something properly here: we *do* have
the possibility to get the untranslated node at the bottom of the stack
by opening the node with O_NOTRANS, don't we? I am almost sure you are
talking about something different, but I cannot figure out what exactly
you mean. Could you please explain?..

>> > You *could* duplicate the proxy data in the shadow nodes, so you
>> > don't have to follow the reference from shadow node to proxy node in
>> > some cases -- but what's the point? Save following one reference?...
>> Hm, really... I'm sorry, I thought we could merge the functionality in
>> a single node because it seemed to me that another node would mean
>> another context switch...
> As in the current implementation the shadow node lives in the same
> process as the proxy node to which it is attached, there is no context
> switch involved...
> That would be different of course if the shadow nodes were indeed
> implemented by distinct translators.
> In either case, it's much to early to think about this kind of
> optimizations.

That's true; I agree :-)

> (Note that this would actually be a case of translator stacking
> optimization -- i.e. a use case for the "mobility framework" Frederik is
> working on. I'm not quite sure whether it's better to create special
> solutions for various use cases first, and only later factor out a
> generic stacking framework, or only work on such optimizations once the
> generic stacking framework is in place...)

Hm... I'm trying to follow your discussion with Frederik, but I'm not
sure I can understand how this could be a use case for the ``mobility
framework''. I guess I should go and read the latest mail in you
discussion, which I skipped do to lack of time.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]