>Alas, the poor man's shared memory from days of yore...
The days of yore I was working in didn't have mmap() either.
This was SVR2 days. The more I learn about Linux, the more
it sure doesn't seem ready for prime time...
>The only _option_ java gives you is threading, because they
>never bothered to implement poll() or select().
Good for them! Those two schlubroutines are on my
personal fecal roster as being two of the grossest
inventions ever. Polling stinks. (Both are actually
polls, but at least SVR3's poll() was honestly named.)
Hate it, hate it, hate it. And I'm sorry, but the sleep .25
in your script version represents a poll, which I object to
on philosophical grounds... While the shell has a nice
wait for X, or wait for all, it doesn't have wait for any,
which is what you need to keep all cores busy with no polling
and no excess forking.
I liked the bit of doggerel, though.
I've got a forking md5sum -c coded, but I'm running into
build environment problems that keep me from testing it.
(Nothing to do with BB's own stuff.) So I don't know if
it works or what the bloat-o-meter says about it...
... OK that's frightening, it worked first time out the chute!
Size: Before: 895041
After: 895473
not including any additional size due to adding the -jN
to the usage message.
Results of "time md5sum -cs /MANIFEST": 14.6
and of "time md5sum -csj2 /MANIFEST": 9.7
both of them from a cold boot. The manifest is for 344 files,
some of them rather large. Not the 2:1 ratio I was hoping for,
but not insignificant when booting an appliance either.
With caches loaded (second invocation) the two times are
3.5 and 2.2 seconds, respectively.
>Taking advantage of SMP is one reason to use threading,
That's where the async I/O I liked best fell down, because
while it was very good at paralleling a lot of work onto a
single CPU it was unable to exploit a second CPU against
the same task set. For that you need threads. (But once
you have threads the same AIO model could work pretty well
again, but of course you'd need explicit thread synchronization
mechanisms that hadn't been necessary before.)
-- Jim
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
