[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Filter design for nsmux
Re: Filter design for nsmux
Fri, 15 May 2009 20:13:54 +0200
On Fri, May 01, 2009 at 10:45:15PM +0300, Sergiu Ivanov wrote:
> On Fri, Apr 24, 2009 at 06:46:40AM +0200, olafBuddenhagen@gmx.net
> > On Thu, Apr 23, 2009 at 04:29:40PM +0300, Sergiu Ivanov wrote:
> > > <olafBuddenhagen@gmx.net> writes:
> > > > So the idea is to have only the first instance do a full
> > > > translator startup. It would do as much common initialization as
> > > > possible; and then some mystical lightweight mechanism would be
> > > > used for launching the other instances from there -- something
> > > > that is much cheaper than normal process creation...
> I see... All this makes the idea very-very interesting :-) I'm reading
> through your blog now, and I'm waiting for another post on *this*
> topic (if you haven't already made one :-) )
I don't think there will be one. That's not really what this blog was
meant for. I fear I already drifted into technical details in some
articles more than I should...
> Could you please point out what could be the problems about modifying
> an existing interface?
Well, I think there are some technical difficulties: the transition
needs to be done carefully; and there is a general risk of breaking
things whenever changing existing stuff.
But that's not really my major concern. The real problem is
organisational: changing an existing interface is a very fundamental
decision, and the current maintainer situation regarding the Hurd means
that there is nobody to approve such fundamental changes... It would be
very hard ever to merge it into the mainline :-(
> > However, now that you mention it, I seriously wonder whether this
> > isn't really what we should do. As reopening with O_NOTRANS has no
> > meaning so far, I guess it wouldn't break anything if we overloaded
> > it with the "obtain underlying node" operation. And it actually
> > makes some sense semantically -- it wouldn't be too ugly a hack I
> > think...
> I'm afraid I must bring bad news: when I try to reopen the port to an
> nsmux node with dir_lookup, control does not get inside
I have a hard time believing this... I'm sure there must be something
wrong with you test setup.
> So, we will probably have to add the new RPC anyway...
I'm not a fan of the "can't get it to work, let's try something
different" approach. If it's indeed impossible to do it like that, I at
least want to know *why*.
> > > > What you wanted to do here is avoiding a context switch, by
> > > > transparently stuffing the functionality of two logically
> > > > distinct translators in a single process. This is *exactly* what
> > > > translator stacking is about...
> > >
> > > Yes, this was exactly what I meant to achieve by merging shadow
> > > and proxy nodes together. Nevertheless, I am rather surprised to
> > > hear that translator stacking is about stuffing the functionality
> > > of two distinct translators in a single process... Actually, what
> > > I understand under ``translator stacking'' is *joining* several
> > > translator processes, not *merging* them.
> > Erm... I'm rather confused. What exactly do you mean by "joining"
> > translators and by "merging" translators? It never occured to me
> > that these terms could be used to describe different things...
> By ``joining'' I mean connecting the process by means of some RPC
> mechanism; exactly what happens in a translator stack: each translator
> runs as a *separate* process, but they are functioning jointly due to
> this connection.
Yeah, that's what "traditional" translator stacking is: One translator
talks to another.
However, I wouldn't call that "joining". They are technically and
logically independent entities, even if they might work together (on the
user's request) to achieve certain functionality...
> By ``merging'' I mean what I understood from your words: putting
> several translators in a *single* process. That is, the difference
> between ``merging'' and ``joining'' in my interpretation is in the
> physical location (and degree of separation) of translators.
Right, that's the purpose of the "translator stacking framework":
Optimize translator stacks by "merging" (in your terminology) several
translators in a single process. Logically they are still independent
entities, but technically they are combined in some way.
(Actually, there are still two processes -- but the functionality of one
of them is migrated over to the other, so one becomes an empty shell,
and the other does all the work.)