On 20 September 2013 12:01, Jakub Jermar <ja...@jermar.eu> wrote: > I believe Martin didn't want to discourage you from contributing to > HelenOS. Neither do I - it is perfectly okay if you try to improve > various areas of HelenOS. But let's also consider the motivation behind > and the need for various changes. > > In this debate, we are faced with something that could be described as > an undesirable domino effect, which is sending tectonic waves throughout > the system. > > It starts with an isolated problem, VFS2 in this case. There you devise > a specialized low-level synchronization primitive for the implementation > of pipes, which you claim is impossible to implement using the standard > primitives. After receiving some doubts and criticism from us about not > using the basic building blocks and having a low-level primitive in the > VFS code, instead of adjusting your VFS2 code accordingly, you decide to > build all fibril synchronization on your new synchronization primitive. > This is basically a device allowing you to keep your VFS pipe code as it > is, instead of rewriting it using the ordinary synchronization.
No, this is completely wrong. I have already rewritten the VFS pipe code to use ordinary synchronization, and I am not pushing it until I have properly tested it. VFS is completely irrelevant here. Temporal relation does not mean one happened because of the other. I mentioned off-topic that sleeper can be used to clean up fibril-async code. Martin challenged me to demonstrate. If he didn't, I probably wouldn't bother yet, but for me this idea is older than any VFS work. > But why > not - the related cleanup seems nice and reasonable. There is only one > problem with it: the timeouts, which can only be done using the async > framework or a separate thread (which is quite cumbersome). So the > fibril and async framework separation (*) and cleanup cannot be entirely > accomplished and therefore you suggest to rewrite the async framework > completely. > > If you read my first message of this thread, you will notice that I suggested rewriting async framework to begin with. In fact, I explicitly said that for fibril_synch, this cleanup doesn't do much, but for async framework, simplification could have bigger effect. If all your interpretation of my work stands of mistaken ideas about my motivation, this is going nowhere. > > (*) This has never been a goal. The goal was never yours to begin with, so how much do you really know about it? All this "goal" and "you should do this instead" and "you are making changes because [some completely misinterpreted fact]" is getting tiresome. There is no meaning of having fibrils > without the async framework and vice versa, just as there is no meaning > of having a scheduler without threads. These two entities can be > somewhat isolated (the split into fibril.c and async.c), but they are > still mutually interwined. That they are. But I am trying to explain that there is no conceptual and practical requirement for it, and that it makes both the conceptual architecture and the implementation itself much more complex than is necessary. So instead of appealing to circumstantial meta-arguments about why I try to change something, can we please at least focus the discussion on the actual subject of the discussion I started? Otherwise why bother discussing at all? -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel
