Yeah, but there still aren't any ShutdownItems on Mac OS X to complement the StartUpItems, so it looks like I have to write an AppleScript app so my client can shut down PostgresSQL safely. And they have to remember to run it every time they want to switch off their iMac.
(Yes this is a plea for help in disguise. If you have solved the problem of running rc.d-ish scripts at shutdown time on Mac OS X 10.2 please leave details.)
PS On the plus side, PostgreSQL 7.3 builds with no errors on Mac OS X, unlike 7.2. This was important enough to me that I used the beta in my (development) code.
Congrats to all involved in this release anyhow.
Yours,
A grateful PostgreSQL User && a pissed off Apple Customer
why i don't give a rat's ass about design patterns
on
Applied Java Patterns
·
· Score: 3, Insightful
Design Patterns should be put in perspective. There are not the be all and end all that some Java/OO zealots make them out to be.
Yes I am aware of select(). select() doesn't really give you concurrency, it just lets you avoid blocking (unless I'm mistaken, which is always possible...). Thanks for the suggestion anyway.
I don't know whether select() would scale; apparently it scales linearly, which is fine when n=20 but not when n=10000. I think if you are going to go with select() you need an implementation that scales logarithmically.
Anyway, to answer my own initial question, there is a paper which I found with a google query and seems interesting.
But processes as provided by current operating systems are too expensive to use. If I have a network server (e.g. a httpd) that has to create a process for each network request, it will never scale. In theory all that has to happen is inetd (or equivalent) fork/execs and does the necessary plumbing so that the ends of the socket are STDIN and STDOUT. Then the process just reads and writes as necessary to fulfil the request. In practice, this just doesn't work.
That's why you can't use cgi for high-volume transactions. So lets make the server a single multithreaded daemon process instead, where each request is handled by a thread. Now you can handle each request much faster, but you lose the protected address space the OS gives you in a process.
Obviously, the OS needs to change, and give use something (maybe a hybrid between processes and threads) that more closely meets applications needs. I don't see anybody making suggestions as to ways to move forward. Anybody know of research in this area?
in fairness UNIX (or at least linux and the BSDs) are comparitively weak when it comes to multi-threading and lots of the slashdot zealots (sue me) could really benefit from actually sitting down with a copy of Inside Windows 2000 rather than just mouthing off about microsoft being evil and windows being crap.
multi-threading is why, for example aolserver can do with one process what apache needs a bunch of processes to do. (though i digress, aolserver only has to run tcl interps, where apache is much more versatile.)
meanwhile, both FreeBSD and NetBSD are trying to get SMP and scheduler activations into their kernels. this would improve their support for multi-threading substantially. there's a paper which explains this better than i ever could.
and this is different from RDF how? an RDF inference engine (together with agreed metadata conventions, like those being worked on by dublin core) would provide the basis for queries against metadata on the web, and that in my opinion what is what's important for the future evolution of the web.
if you haven't looked into RDF and the importance of metadata on the web, there's no time like the present.
it wouldn't hurt to read weaving the web, by tim berners-lee, the inventor of the world-wide web, either. he has chapter 1 online.
Slashdot Mirror
BAD Apple! No biscuit!
(Yes this is a plea for help in disguise. If you have solved the problem of running rc.d-ish scripts at shutdown time on Mac OS X 10.2 please leave details.)
PS On the plus side, PostgreSQL 7.3 builds with no errors on Mac OS X, unlike 7.2. This was important enough to me that I used the beta in my (development) code.
Congrats to all involved in this release anyhow.
Yours,
A grateful PostgreSQL User && a pissed off Apple Customer
Propoganda
Design Patterns in Dynamic Programming
"Design Patterns" Aren't (google cache link)
That said, thanks for the information, it has certainly helped to clear some things up.
I don't know whether select() would scale; apparently it scales linearly, which is fine when n=20 but not when n=10000. I think if you are going to go with select() you need an implementation that scales logarithmically.
Anyway, to answer my own initial question, there is a paper which I found with a google query and seems interesting.
But processes as provided by current operating systems are too expensive to use. If I have a network server (e.g. a httpd) that has to create a process for each network request, it will never scale. In theory all that has to happen is inetd (or equivalent) fork/execs and does the necessary plumbing so that the ends of the socket are STDIN and STDOUT. Then the process just reads and writes as necessary to fulfil the request. In practice, this just doesn't work.
That's why you can't use cgi for high-volume transactions. So lets make the server a single multithreaded daemon process instead, where each request is handled by a thread. Now you can handle each request much faster, but you lose the protected address space the OS gives you in a process.
Obviously, the OS needs to change, and give use something (maybe a hybrid between processes and threads) that more closely meets applications needs. I don't see anybody making suggestions as to ways to move forward. Anybody know of research in this area?
multi-threading is why, for example aolserver can do with one process what apache needs a bunch of processes to do. (though i digress, aolserver only has to run tcl interps, where apache is much more versatile.)
meanwhile, both FreeBSD and NetBSD are trying to get SMP and scheduler activations into their kernels. this would improve their support for multi-threading substantially. there's a paper which explains this better than i ever could.
thanks for the info.
http://www.rhyolite.com/anti-spam/dcc
the way he talks, you'd think he runs ATC systems at weekends as a hobby.
when i read that i just thought "what a stupid comment" and tuned out.
the link: http://www.marine-monsters.com/front/products/digi q.html
(this is just adding information to the instructions provided in nt/Install in the source distribution.)
if you haven't looked into RDF and the importance of metadata on the web, there's no time like the present.
it wouldn't hurt to read weaving the web, by tim berners-lee, the inventor of the world-wide web, either. he has chapter 1 online.