concurrency ideas inspired by obj'c

4.13: adda/oop/co/concurrency ideas inspired by obj'c:
. obj'c has a callback pattern
where a service provider is customizable
by expecting the clients to provide certain functions
that the service provider will call at special times .
. obj'c's callbacks will have a param indicating
which object is the service provider doing the callback
-- apple calls that the msg sender --
but that is generalizable as the caller:
each call is part of a call stack,
and we don't need to include the caller in the parameter
because the system can provide that as stack(-1),
eg, the adda language could reserve the term:
self`caller
( however, notice in pure oop, callers are
always obj's, not subprograms .
when a service provider is calling you back,
you don't want to know which of its subprogram's called you back;
you want a way to refer back to the service provider .
. the key to sorting this out is noticing
when there is cross-module communications .
. are all objects to be treated as separate processes?
)
. is there a distinction between caller and msg sender?
are objects async'ly called ? generally not,
since the call's parameters could be
references to caller's internals;
so, the caller is going to want to
wait for the call to finish .
. even if the callee is not writing to a shared object
the caller has to avoid writing until callee is done,
or it has to be a dynamically updateable type
(2 threads must agree to release as often as possible).
. if not waiting for callee to return,
there must be a lock on the refs target,
when callee is done handling the msg
the system has to notice if any params are pointers
and unlock the targets when the call is done;
ie,
the caller usually knows when a call is done,
because it wouldn't be runnable
unless all its callees had returned;
so, during an async call, the caller is still running
until it bumps into a locked resource,
and when the async callee returns,
the system must provide a notification,
and upon notification the caller can unlock the resources
that it had let that callee borrow,
or the system's notification could consist of
auto'ly unlocking what was shared with the callee .
. unlocking means decrementing an [in use by a callee].counter,
since with async calling concurrently,
there could be multiple readers locking out writers .
... may want to review
what's already been written about this;
but generally,
it would be nice to have a way for the caller
to know when an async callee is done
the async syntax could be
has-returned.flag`= async y`= f(x) .