From: "Scott Gilbert" <xscottg@yahoo.com> > > --- Thomas Heller <thomas.heller@ion-tof.com> wrote: > > > > > This restricts the set of objects that can be buffers to statically > > > sized objects. I'd prefer that dynamically resizable objects be able to > > > be buffers. > > > > > > > ..., but I understand Neil's requirements. > > > > Can they be fulfilled by adding some kind of UnlockObject() > > call to the 'safe buffer interface', which should mean 'I won't > > use the pointer received by getsaferead/writebufferproc any more'? > > > > I assume this means any call to getsafereadpointer()/getsafewritepointer() > will increment the lock count. So the UnlockObject() calls will be > mandatory. Either that, or you'll have an explicit LockObject() call as > well. What behavior should happen when a resise is attempted while the > lock count is positive? This question is not difficult to answer;-) The resize should fail. That's the only possibility. If this can be handled robust enough by the object is another question. Probably this all is too complicated to be solved by the safe buffer interface, and it should be left out? Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4