On Jun 9, 2008, at 10:32 AM, Karl Robillard wrote:
I don't see any real difference. In fact, OS portability is
probably the
easier part to achieve due to existing standards (TCP/IP, OpenGL, etc)
TCP/IP? Great, let's write a web server! It'll fork() to accept every
connection. No, wait, fork() is almost unusably slow on Solaris for
this purpose. I guess we'll do threads. Except hmm, creating a thread
on Solaris can be slower than forking a process in Linux on the same
hardware. I guess we'll deal with it. We can accept our timeouts with
SIGALRM. No, wait, that's expensive, we should just do select(). But
wait, select() has a limit on the number of fds. 1024 on Linux and
maybe less on other platforms. We should use poll() instead. No, wait,
Mac OS X doesn't support that. I guess we could use the proprietary /
dev/poll on Solaris and epoll via syscalls on Linux 2.6, and support
SIGIO if we want to compile on Linux 2.4. That should work. Except BSD
doesn't have any of this, so we'll support kqueue on FreeBSD and
OpenBSD, but not NetBSD which doesn't have it. We'll select() there, I
suppose. Okay, so now we have a webserver. It'll do zero-copy file
sends back to clients via sendfile(). Wait, but that syscall is
different on FreeBSD and Linux. And doesn't exist on NetBSD and
OpenBSD. And we better not try mmaping the file, because mmap()
latency increases significantly with the number of pages mapped in
NetBSD, FreeBSD and old Linux kernels. Maybe we'll do AIO on Linux to
avoid a blocking sendfile() and just send chunks straight out of /dev/
shm. But the AIO semantics are different on FreeBSD, and we better not
try it on Solaris whose POSIX AIO implementation is stubbed out and
returns ENOSYS for every call. I guess we'll use AIO+splice on Linux
even though splice() doesn't exist elsewhere...
Citing a cruel, cruel world, web server writer performs ritual self-
disembowelment by sharpened keyboard, news at 11.
--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
