From 6f3a380f3c1bc602b1b86dec307abf27f71bfef4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 28 Jan 2012 15:04:40 +0100 Subject: IRC. --- open_issues/anatomy_of_a_hurd_system.mdwn | 146 +++++++++++++++++++++++++++++- 1 file changed, 145 insertions(+), 1 deletion(-) (limited to 'open_issues/anatomy_of_a_hurd_system.mdwn') diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 13599e19..99ef170b 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -122,3 +122,147 @@ IRC, OFTC, #debian-hurd, 2011-11-02: system (via libdiskfs). sekon_: This may help a bit: http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html + +--- + +IRC, freenode, #hurd, 2012-01-08: + + can you tell me how is done in hurd: "ls | grep x" ? + in bash + ls's standard output is a port to the pflocal server, and grep x's + standard input is a port to the pflocal server + the connexion between both ports inside the pflocal server being + done by bash when it calls pipe() + youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists + ? + sure, hurd is compatible with posix + so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at + the pflocal server, then connects both ends to T1 and T2, then start(T1), + start(T2) ? + not exactly + it's like on usual unix, bash creates the pipe before creating the + tasks + then forks to create both of them, handling them each side of the + pipe + ok I see + s/handling/handing/ + but when you do pipe() on linux, it creates a kernel object, this + time it's 2 port on the pflocal ? + yes + how are spawned tasks ? + with fork() ? + yes + which is just task_create() and duplicating the ports into the new + task + ok + so it's easy to rewrite fork() with a good control of duplicated + fd + about threading, mutexes, conditions, etc.. are kernel objects or + just userland objects ? + just ports + (only threads are kernel objects) + so, about efficiency, are pipes and mutexes efficient ? + depends what you call "efficient" + it's less efficient than on linux, for sure + but enough for a workable system + maybe hurd is the right place for a userland thread library like + pth or any fiber library + ? + hurd already uses a userland thread library + libcthreads + is it M:N ? + libthreads, actually + yes + nice + is the task scheduler in the kernel ? + the kernel thread scheduler, yes, of course + there has to be one + are the posix open()/readdir()/etc... the direct vfs or wraps an + hurd layer libvfs ? + they wrap RPCs to the filesystem servers + the Bushnell paper is probably the closest we have to a high-level + documentation of these concepts... + the Hurd does not have a central VFS component at all. name + lookups are performed directly on the individual FS servers + that's probably the most fundamental design feature of the Hurd + (all filesystem operations actually, not only lookups) + +IRC, freenode, #hurd, 2012-01-09: + + youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1 + and no modern OS is a right place for any thread userspace + library, as they wouldn't have support to run threads on different + processors (unless processors can be handled by userspace servers, but + still, it requires intimate cooperation between the threading library and + the kernel/userspace server in any case + braunr: in libthreads, they are M:N + you can run threads on different processors by using several kernel + threads, there's no problem in there, a lot of projects do this + a pure userspace library can't use kernel threads + at least pth was explacitely used on systems like bsd at a time + when they didn't have kernel threads exactly for that reason + explicitely* + and i'm actually quite surprised to learn that we have an M:N + threading model :/ + why do you say "can't" ? + but i wanted to reply to abique and he's not around + of course you need kernel threads + but all you need is to bind them + well, what i call a userspace threading library is a library that + completely implement threads without the support of the kernel + or only limited support, like signals + errr, you can't implement anything with absolutely no support of + the kernel + pth used only SIGALRM iirc + asking for more kernel threads to use more processors doesn't seem + much + it's not + but i'm refering to what abique said + 01:32 < abique> maybe hurd is the right place for a userland + thread library like pth or any fiber library + well, it's indeed more, because the glibc lets external libraries + provide their mutex + while on linux, glibc doesn't + i believe he meant removing thread support from the kernel :p + ah + and replying "nice" to an M:N threading model is also suspicious, + since experience seems to show 1:1 models are better + "better" ???? + yes + well + I don't have any time to argue about that + because that'd be extremely long + simpler, so far less bugs, and also less headache concerning posix + conformance + but there's no absolute "better" here + but less performant + less flexible + that's why i mention experience :) + I mean experience too + why less performant ? + because you pay kernel transition + because you don't know anything about the application threads + etc. + really ? + yes + i fail to see where the overhead is + I'm not saying m:n is generally better than 1:1 either + thread switch, thread creation, etc. + creation is slower, i agree, but i'm not sure it's used frequently + enough to really matter + it is sometimes used frequently enough + and in those cases it would be a headache to avoid it + ok + i thought thread pools were used in those cases + synchronized with kernel mutexes ? + that's still slow + it reduces to the thread switch overhead + which, i agree is slightly slower + ok, i's a bit less performant :) + well don't futexes exist just for that too ? + yes and no + in that case they don't help + because they do sleep + they help only when the threads are living + ok + now as I said I don't have to talk much more, I have to leave :) -- cgit v1.2.3