Hi,
I think this was the start of the regression that basically caused
the regression introduced by d232e92794c74a326d1e48355d257f24a6d497c2
("Use GQueue for RedCharDevice::send_queue").
Basically on cc47d9eba84d33012da660d7dcee3a6e3eb8d99f
("reds: Derive VDIPortReadBuf from PipeItem") VDIPortReadBuf was derived
from PipeItem (now RedPipeItem) mostly to reuse reference counting
(and possibly free). However this was propagated to RedCharDevice
where read_one_msg_from_device and send_msg_to_client use RedPipeItems
but leaded to imagine that RedPipeItems could be inserted in multiple
client pipes which is basically would cause a spice_assert.
As said in https://lists.freedesktop.org/archives/spice-devel/2016-May/029204.html
this does not cause the crash as multiple clients is not supported
however I think this as a bad design. Simply we should have a class
to represent a data buffer with:
- reference counting;
- embedded destroy.
This would simplify CharDevice and agent code and avoid the wrong
assumption that caused d232e92794c74a326d1e48355d257f24a6d497c2.
This will probably rollback some code and introduce back a RedPipeItem
however I think all this was and will be the right way. "Was" as all these
changes allowed some callbacks and many code to be removed or simplified.
"Will" as it's the shortest path to remove regression (which IMHO should
be short as possible).
Frediano
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel