Callback Registration

Hi,

I was sick earlier in the week and did not feel up to thinking about
IMs . . . Now I'm better and have a few thoughts to add to the
callback registration IM-324.

I still feel the option to make callbacks persistent need to stay in
the standard. However, I am fine with Amy's proposal for the dynamic,
one-time callbacks. That style of callback need to be one-time as it
depends on a dynamic condition and thus it does not make sense for it
to be persistent. I did not think about such a use model when I previously
opposed one-time callbacks. This is also a clear step beyond the original
idea behind the callback mechanism which was first put in place only
to allow the construction of the blocking API. Now, this new style of
callback creates a different use model that is useful.

On the topic of multiple callbacks, one downside of multiple callbacks
is that the user will no longer be able to wedge in his own callback
to keep tabs/peek at/modify what the blocking API callback is doing. I
think Amy was suggesting such a use for profiling, for example. With
multiple callbacks you don't get to chain your callback to another
callback. Is this a serious issue? Probably not, but it's on the
table . . .

Although it is not recommended to mix the blocking and non-blocking
API on the same pipe, we do not enforce this. This can cause some
headaches with the callbacks as the blocking API needs its callback
and the user needs his own. One way of solving it is allowing for
multiple callbacks (a generalization of 2 callbacks: a private,
blocking API-only callback, and the public callback provided by the
non-blocking API). However, that only guarantees that both the
blocking API and the user gets their callbacks called. However, it
does not guarantee correct behavior as one callback could be taking
elements from the pipe that the other callback would not get to see.

There may be another way without resorting to multiple callbacks.
In the reference code for the blocking API, the callback registration
is done on the fly. What if we added an API call to initialize the
pipe for blocking API use? That init call could register the blocking
API callback and perhaps do other setup. Then the send and receive
functions won't have to do on the fly callback registration. We would
need to specify that, if the user later calls the register function,
they need to keep in mind that they will be overriding the blocking API
callback function and will be responsible for calling it themselves
from within their callback, e.g., implement chaining. We can even
provide a simple code example for how to do this.

Another aspect of multiple callbacks that comes to mind is the following:
We have already discussed that the order of calls of multiple callbacks
need to be addressed by the standard (either make it undefined or perhaps
make it ordered by registration order). But we also need to define what
each callback will see. All callbacks are called for the same reason,
but if one callback decides to get elements out of the pipe, will this
change the state of the pipe for subsequent callbacks or will subsequent
callbacks see those elements still in the pipe?

BTW, the idea of 2 callbacks, i.e., one for the blocking API and
one for the non-blocking API, is not a great idea as it would make
the blocking API non-implementable on top of the non-blocking API.

Thanks,
Per

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.