scheduler is completely cooperative, and "managers" are just fibrils
that handle IPC events and for some reason are treated specially.
Well, you have an interesting way how to approach things -- dismissing
everything that is not immediately clear to you as too complicated,
probably broken and a target for your next rewrite.
But surprisingly, most parts of HelenOS are not designed by accident and
sheer incompetence, although the motivations for some particular designs
might not be always instantly obvious (which is, of course, a problem of
the documentation must be addressed ultimately, but that's a different
story).
The manager fibrils are treated specially because they are special, from
the software architecture point of view. They are deliberately set aside
because they do something else than implementing the business logic of
the task. Whether that means that they have relatively little to do
right now is not so important.
You could just as well have fibril implementation itself put threads to
sleep when there are no fibrils to run, and woken up when there is new
work
Yes, of course, you could. There is an infinite number of different ways
how to implement event loops, threading, etc.
But unless our current way is broken in some fundamental way or lacks a
feature you desperately require I see little reasons for a major rewrite
of the code that is totally and utterly unrelated to your original goal,
which is getting your VFS2 stuff integrated. Aren't you just totally
losing focus?
I mean, I can have millions of objections to how Bash and Firefox are
implemented, but I try to restrain myself from rewriting Bash and
Firefox every time I need to write a shell script or view a web page :-)
Also, load-balancing code does not depend on whether or not there are
managers, but whether or not fibrils migrate between them freely, which
they currently do. If they did not migrate, and there was per-thread run
queue, there would be need for special balancing code regardless of
managers.
The question is where should this code reside eventually. I think the
manager fibril is a perfect place to put any such current or future
bookkeeping code.
We are currently doing the same thing with fibril stacks. One fibril
dies and it gets released in context of the next fibril. It would
actually help to maintain a pool of free stack pages, as you wouldn't
need another fibril to do the cleanup.
The fibril pool will naturally also retain the fibril stacks.
Since currently managers do
nothing to solve this, I don't see what is the problem you are getting at.
Yes, currently they don't. But they might be quite handy when they start
doing it.
It is really not in my nature to limit people in their initiative and I
appreciate any discussion with you about how things could be improved.
But in my personal opinion you are now switched to a mode where you tend
to rewrite everything you touch only because you simply don't appreciate
how it is done now.
You are just fixing things that are not broken.
If you don't get your focus under control, next week you'll be writing
to Intel about the problems of the IA-32 instruction set :-D
M.D.
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
