On 11. apr. 2010, at 17.56, KaiGai Kohei wrote: > > It seems to me the new get_item_info() interface intends to contain various > kind of properties more than bare threes (value, cas and expired time), > because we can easily expand the number of 'struct iovec value[]' in the > new item_info. >
That's not what the iovector is intended for. The network protocol specifies the attributes we use for an item (we need a new network protocol to encode other attributes), so that wasn't what I planned to use the iovector for. The usecase for the iovector is to allow the engines to store their items as multiple fragments (and not have to concatenate them into a single object before returning it to the core. (please note that currently the iovector is _never_ bigger than one element, but I'm planning to fix that this week. The reason I didn't add that to the allocate function is that it would complicate the state machine in the core. I would think that most engine writers could live with allocating a continuous segment during allocation, and then store it in multiple segments when the user calls store(). Trond -- To unsubscribe, reply using "remove me" as the subject.
