Proposal to change the way asynchronous function calls are signalled, and to deprecate (@ @) `operator'

Jonathan Poole

A postscript version of this whole document is available here

The latex source is available here

The current system of implementing the call to asynchronous functions is fatally flawed and needs changing. An alternative is suggested.

The current system is that an extra argument is added to the end of the parameter list. There are two problems with this method:

In fact it seems that in general we cannot use the parameter list as a method of passing information about the way the function is called. We must find a different way to pass information to the object indicating that the call is to be asynchronous etc.

The best alternative is unclear. Some possibilities are:

  1. using a macro, eg
    ASYNCH(UCPPOBJECTPTR -> FunctionName(arguments))

    This would allow the use of message system operators before and after the call, for example it might expand to:

    MessageSubsystem -> SetNextCallAsynchronous();
    UCPPOBJECTPTR -> FunctionName(arguments)
    MessageSubsystem -> SetSynchronous();

  2. using a function that applies to the pointer, for example use
        asynch(UCPPOBJECT) -> FunctionName(arguments)
    where asynch() is a function that takes a pointer to a UC++ object, sets a field in the object saying `next function along is asynchronous' and then returns the pointer.

  3. have a member function of UC++ classes that sets mode asynchronous and returns the pointer, so you can do:

        UCPPOBJECT -> asynch() -> FunctionName(arguments)


  4. use smart pointers for UC++ objects, so that the pointer object can itself have operators or member functions. We might for example have the operator `--' defined on UC++ pointers so asynchrous calls have a `long arrow'

        UCPPOBJECTPTR ----> FunctionName(arguments)

    This is perhaps obscure, but something like:

        UCPPOBJECTPTR.asynch() --> FunctionName(arguments)

    is quite nice. Problem with this method is that all pointers to UC++ objects then have to be smart pointers.

  5. extending the idea above, have a general calltype, which takes a first class object, so we have

        UCPPOBJECTPTR.CALLTYPE(asynchronous) --> FunctionName(arguments)

    This would allow the passing of information about types of calls etc. at run-time. Might be other information we want to put in (e.g. ignore return type), result only useful if within X seconds etc.

Some of these schemes have simple extensions to deal also with operators.

ISSUES FOR DISCUSSION: there are several potential wrinkles with this scheme. Would need to be quite carefully designed.

In particular the method chosen has to be thread safe---the whole function call operation has to be atomic as we are setting modes.

A big issue waiting to be solved is that of return values from asynchronous function calls. When designing a method of signalling asynchronous calls we should think also about return values and build a scheme that encompasses them.

We should build a call mechanism that is clean enough for the end programmer to use, as we should deprecate the use of the (@ @) operator as it is an unnecessay extension of C++ syntax. If we get rid of it and activenew the user of a set of UC++-assisted libraries would not need to know anything about UC++.

Jonathan Poole
Wed Aug 2 17:53:11 BST 1995