Messages in this thread | | | From | (david parsons) | Subject | Re: Where else would you put a database? | Date | 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/
| |