<olafbuddenha...@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, <olafbuddenha...@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. Regards, scolobb
