Lennart Poettering wrote, On 12/22/2009 07:00 PM: > On Mon, 14.12.09 20:16, Mads Kiilerich (mads at kiilerich.com) wrote: > >> The streams.h documentation tells how the write pointer can be moved >> with pa_stream_write() - and reset with pa_stream_flush(). >> >> But AFAICS there is no way to move the write pointer without writing >> anything. pa_stream_write() has assertion on data not being NULL and >> doesn't move the pointer if nbytes is 0. >> >> Is there some kind of trick that can be used? >> > One option is to simply cache the seek position locally and then use > it the next time you write again. > >> Would it make sense to change PA so pa_stream_write() accepts a NULL >> pointer if nbytes is 0 and then just moves the write pointer? >> > Not sure if that really is advisable. We should minimize the traffic, > and thus I'd say that seeking without writing is a redundant > operation... > That is good points. But I think there are good counter arguments and that my proposal makes sense anyway: I assume that PA already maintains a pointer to where the next write should happen. Changing that pointer without doing anything else can't be an expensive operation. Maintaining state and functionality for "should I make a relative seek on next write" in applications would be more complex and introduce extra (but cheap) code in the hot code path. Seeks are generally an exception which doesn't happen often, and an extra redundant operation in that case is acceptable. IMHO. pa_stream_write() does two things: seek and write. It is obvious what to expect if you make a seek without writing anything - that requires no explanation. It is obvious that making two calls to a function is more expensive than one, and that combining two calls to one is an optimization which should be done if relevant. But it is surprising and counter-intuitive that pa_stream_write() can't "write" a zero-length chunk like for example write(2) can. The current behaviour has a special case which need documentation. The behaviour I propose will remove a special case and no extra documentation is necessary, and it will thus reduce the complexity of the API. /Mads
