lkml.org 
[lkml]   [1998]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Where else would you put a database?
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.084 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site