Re: Where else would you put a database?
david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
16 Dec 1998 15:43:24 -0800
In article <linux.kernel.3677F575.F00C14BC@gmx.de>,
Edgar Toernig <froese@gmx.de> wrote:
>david parsons wrote:
>> It's an application, and userland is an *ideal* place to put applications.
>
>Edgar Toernig <froese@gmx.de> wrote:
>> The buffer cache and the low level btree/record management should be in the
>> kernel. It's really hairy (and slow) to implement this for concurrent
>> access in user space. A generic locking mechanism would be another candidate.
>
>david parsons wrote:
>> Why? It's not as if the relational database will be sharing any of
>> its data areas with any other applications
>
>If the app is single threaded and it is the only user of the file
>everything is peanuts. If it's multi threaded you have two variants:
>A) Everything is done in a single process or B) multiple processes
>try to access the file at the same time. In case A the app has to
>deal with multi threading itself which means you have to implement
>a scheduler, locking schemes, buffer management, asynchronous I/O, ...
Yes, and your point? (Actually, you *don't* need to implement a
scheduler, unless you have specific needs that require one; rather
like relational databases has a specific need that really really
wants to be able to talk directly to a disk.)
If you saying that any multithreaded application needs to operate
in kernel space, well, that's certainly a novel view to me. But
it's not one I'm not interested in debating on the kernel mailing
list, because I suspect it would rapidly LUNGE into being an
argument about theory of computing.
____
david parsons \bi/ Eggs. Your grandmother. No need to teach.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/