[Bug 754826] memory: add remap operation

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=754826

Olivier Crête <olivier.crete at ocrete.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olivier.crete at ocrete.ca

--- Comment #6 from Olivier Crête <olivier.crete at ocrete.ca> ---
(In reply to Matthew Waters from comment #5)
> (In reply to Olivier Crête from comment #3)
> > The whole undo operation feels fishy to me, I'm not sure how a undo is
> > different from modifying the flags again? Although locking downgrades seem
> > find, locking upgrades seem like a risky idea. Downgrading and then
> > re-upgrading seems downright wrong for example as someone else could have
> > mapped it for reading while that happens and then you won't be able to
> > re-upgrade!
> 
> Actually, you will be able to reupgrade in that case.  The more dangerous
> case is first adding a write map and then undoing with a potential map with
> the write bit in between.

I think if you only downgrade, remapping can never fail, in the worse case, the
buffer will still be mapped as RW internally even though the elements think
it'S RO, no ? I would never allow adding write, only removing it.



> > I'd have a simple
> > gst_mini_object_downgrade_lock(GstMiniObject, gint flags_to_drop);
> 
> That's what I started with :) however videometa has its own map()/unmap()
> and now remap() vfuncs which may also need/want to undo a remap operation
> unless we attempt something else.

I'm not sure why those would want to undo if we saw that we only allow
downgrading?

> The question is what does an API user do if the memory remap operation
> fails.  As far as I see it, we have a two of options.
> 1. do nothing (easy)
> 2. attempt to rollback (hard)

How can a downgrad remap fail?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.