On 10/07/2024 11:53, zxuiji wrote:
> I say copy what the kernals do, move to an index based ABI. You create
> some ioctl like function for every thing, including memory allocations.
> Then you create yet another function like it for synchronised mode,
> something like this:
>
> int32_t stdiocall( int32_t index, int32_t call, va_list )
> {
> int32_t res = -1;
> stdref *ref = getstdref( index );
> if (ref->semaphore == INVALID_SEMAPHORE )
> return (ref->creator != gettid) ? EPERM : stdrefcall( ref->ud,
> call, va );
> if ( ref->wrlock == gettid() )
> return stdrefcall( ref->ud, call, va );
> if ( lock( ref->semaphore ) != 0 )
> return errno;
> res = -1;
> // Does the call modify ref->ud?
> if ( call & 0x1 )
> ref->wrlock = gettid();
> else
> ref->rdlock++;
> unlock( ref->sem );
> if ( call & 0x1 )
> {
> while ( ref->rdlock ) yield();
> res = stdrefcall( ref->ud, call, va );
> ref->wrlock = -1;
> return res;
> }
> while ( ref->wrlock ) yield();
> res = stdrefcall( ref->ud, call, va );
> if ( lock( ref->semaphore ) != 0 )
> return errno;
> ref->rdlock--;
> unlock( ref->semaphore );
> return res;
> }
>
> With this setup not only do you provide a consistent ABI to interact
> with internal objects with but you also take care of thready safety in
> the process. Can just have an optional stdrdlock/stdwrlock/stdunlock set
> of functions for when multiple calls need to be made in a loop

That's a possible method to provide encapsulation, but it does nothing
to address the existing issue of involuntary ABI ossification. I would
consider this to be an implementation detail that can be left to whoever
is implementing a public interface.

The focus of the paper is not on how to implement such interfaces,
however, it is on communicating (and enforcing) that library classes are
subject to change in future library revisions, and therefore not safe to
use in public interfaces.


Hans Guijt