> > > Every writer has a different size of write it needs to make, and you >> don't want to cut off the data arbitrarily, not when multiple writers >> are competing for the channel. Then you need to know what amount of >> buffer space the next writer will need, but you don't know which writer >> is the next one to wake up. I don't see how to work around that. >> > > This issue is usually solved by providing a constant upper bound on the > size of the write that is guaranteed not to be cut off. All you need then > is to set the pipe's internal buffer size according to this upper bound > (usually the same) to make it work. > > For example, in POSIX, since the write() does not warrant that it will > always be able to write something, this semantics is an improvement over > the general case. > > The idea that you don't want to cut off the writer ever (without a > reasonable upper bound) can be actually quite unfair to other writers. Just > imagine a malicious writer that is about to write a few gigabytes into the > pipe using a single call. > > I think this guaranteed size should (for the sake of consistency) be the same as the maximum allowed size of IPC data write, which currently is 64kB. As long as you don't want the writer to wait for its data to be read, it would work. It would actually work better than the current implementation, since it seems it just pairs the writer with the first reader. The only problem I see is that for the usual case, every pipe would have almost 64kB of unused buffer space. Unless the pipe always keeps track of the maximum size that any writer wants to store, which is still not as elegant as assuming that writers can't be reordered by the condvar. Currently condvar implementation does guarantee FIFO ordering, but I am not sure how sane it is to assume this won't change.
-- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
