At Thu, 3 Nov 2005 11:21:17 -0700, "Christopher Nelson" <[EMAIL PROTECTED]> wrote: > Sure, but in practice how does this work?
In practice it works by first defining what your system looks like, and then finding out what the constraints are. The problems you describe stem from the fact that you have a service that is used by multiple users concurrently, and which expends some of its own resources in handling those messages. Under this constraints, you are already violating a number of good principles. But let's say that you figure out this is ok in this circumstance. Then the least you must do is to ensure that all requests the service processes have a fixed upper bound, preferably a really, really small one. > > To say that the one or the other is stupid is just plain wrong. > > > > Sometimes you should support dynamic reallocation. Sometimes > > you should have a fixed buffer and truncate. You should not > > limit your toolset because of some half-cooked and > > (generally) _wrong_ programming dogmas. > > I think it is wrong to have an arbitrary global limit, but I don't > think that an application imposing an arbitrary *reasonable* limit > is wrong. Because we *can* do something is not a good argument for > actually doing that something. If all you are saying that a system-wide limit is wrong, then think again: A system-wide limit is impossible to enforce. It is totally possible for you to set up your own filesystem server, expending your own resources, in which arbitrary long filenames are mapped transparently to the short "system-wide" limit. Nothing can stop you from doing so. So the whole notion of "global limit" is complete and utter non-sense. However, _if_ there is a shared service in your system, then for all I know the only sane implementations possible will be one that imposes strict limits on the argument sizes it supports. You want to use another party's resources, you play by their rules. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
