On 7/10/07, skaller <[EMAIL PROTECTED]> wrote: > > HOF aren't necessarily slow. Try this program with
I'm not really concerned about speed. And your example is neat by the way. :-) HOF are really needed when one needs abstraction. I'm just saying that I suspect that the abstraction won't be needed, because all VM calls will be very simple, low-level functions which operate in a straightforward, sequential fashion. HOF don't really help much in this scenario. But as I said, if I see an opportunity for their use, I will definitely use them. > > The problem is that without precise information, you can't make the > > "kill process" judgment with any accuracy; you're left with heuristics > > as in Linux/Unix of killing processes off randomly (although you might > > have more information in this case). > > Estimation is the art of limits .. you don't need precise information, > just 'good enough' estimates. > > Precise information is too expensive .. What do you see as too expensive exactly? The allocation routine has an integer quota, and an integer "current allocation count". Once the current meets or exceeds the quota, A GC is run for that process; seems this would translate to about 6 or so instructions using a bump pointer GC. The accounting algorithm is part of the GC, and the PLT scheme paper demonstrates overheads on the order of 3% IIRC. > and will itself open up the possibility of a DoS attack! Just flog the system > with a bytecode that makes lots of allocations.. :) Ah, but the point is that allocations and garbage collection is performed under the agent's own schedule. This aligns their incentives with good behaviour, because they can't misbehave and adversely affect others, ie. no tragedy of the commons. They're just using up their *own* resources. > > > There's some support for async disk file I/O, but really > > > Linux can't do this so it's fairly pointless. > > > > Well, some web servers seem to do fairly well with epoll (see lighttpd, et > > al). > > We're using epoll on Linux, but it only works for sockets > because when you do I/O on notification .. that I/O isn't > asynchronous. Sendfile (disk to socket) is supposed to be, > but I have my doubts. Right, I really meant non-blocking, of which asynchronous calls is a possible approach. One can easily build asynchrony on non-blocking semantics. Sandro ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
