Non-system asyncs

Non-system asyncs

[Neil Jerram]

Hi Marius,

I like your work and docs on system asyncs.  But I still don't see
what the point of non-system asyncs is -- they seem to be the same as
hooks, but with a less convenient interface.  Couldn't we deprecate
(and later remove) non-system asyncs?

        Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Non-system asyncs

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I like your work and docs on system asyncs.  But I still don't see
> what the point of non-system asyncs is -- they seem to be the same as
> hooks, but with a less convenient interface.

I'd say they are somewhat different from hooks in that you can decide
'dynamically' which procedures to call.  It is probably awkward to try
to implement user asnycs with hooks.  But I agree that they feel a bit
out of place, next to the system asyncs that provide a 'real'
low-level service that you couldn't get otherwise.

> Couldn't we deprecate (and later remove) non-system asyncs?

Hmm, are they causing harm?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Non-system asyncs

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> [...]  But I still don't see
    >> what the point of non-system asyncs is

    Marius> I'd say they are somewhat different from hooks in that you
    Marius> can decide 'dynamically' which procedures to call. [...]

    Marius> Hmm, are they causing harm?

Kind of, in that I'd like to document them intelligently -- which
means explaining why as well as what and how -- and I currently can't
see how to do that.

Perhaps the key is that I don't understand what you mean by deciding
dynamically which procedures to call - can you explain again?

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Non-system asyncs

[Tom Lord]

    >> [...]  But I still don't see
    >> what the point of non-system asyncs is


Asyncs (both "system" and "non-system") are a mechanism for scheduling 
asychronously invoked computation that can not be explained by the 
semantics of ordinary evaluation.

My program is running along and, all of the sudden, out of the blue,
some function is invoked whose invocation can't be explained by the
source of the procedure being run at the time.   That's an async.

It's a partial alternative to threads for single-CPU applications.

System interrupts are well-described by asyncs.  Oops -- I got SIGHUP
-- run the SIGHUP handler.

But why does the kernel get to define the set of asyncs?   Why not
also have "synthetic asyncs"?   It's a way to say to the
implementation: "here's a computation that you should run as soon as
you can, regardless of whatever else is going on".

One might do incremental display updating that way, for example.


-t




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Non-system asyncs

[Neil Jerram]

>>>>> "Tom" == Tom Lord <lord@regexps.com> writes:

    Tom> Asyncs (both "system" and "non-system") are a mechanism for
    Tom> scheduling asychronously invoked computation that can not be
    Tom> explained by the semantics of ordinary evaluation. [...]

Thanks for the great description - it might be nice to incorporate
some of this into Marius's improved async docs.

However... it only makes sense for _system_ asyncs!

It isn't true for non-system (aka "user") asyncs that "some function
is invoked whose invocation can't be explained by the source of the
procedure being run at the time", because non-system asyncs have to be
run explicitly by calling `run-asyncs'.

In particular --

    Tom> But why does the kernel get to define the set of asyncs?  Why
    Tom> not also have "synthetic asyncs"?  It's a way to say to the
    Tom> implementation: "here's a computation that you should run as
    Tom> soon as you can, regardless of whatever else is going on".

-- absolutely, but in current Guile these are still "system" asyncs,
even when the computation is user-specified: see `system-async-mark'.

    Tom> One might do incremental display updating that way, for
    Tom> example.

Excellent example, but still an application of "system" asyncs.

So, unless I'm still missing something, your excellent description
just reinforces my point that non-system asyncs are pointless.

(Just a thought - is it possible that the semantics of non-system
asyncs might have changed since you knew them closely?)

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Non-system asyncs

[Tom Lord]

       > -- absolutely, but in current Guile these are still "system" asyncs,
       > even when the computation is user-specified: see `system-async-mark'.


Blush.  I forgot about that -- asyncs as just a data structure.

Yeah, they are probably extraneous.

-t




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Non-system asyncs

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Perhaps the key is that I don't understand what you mean by deciding
> dynamically which procedures to call - can you explain again?

A hook is a list of procedures that should be called at certain points
in a program.  When the point comes, all procedures are called.  User
asyncs are also gathered into a list, and they are run at certain
points in the program.  However, only those asyncs that have been
marked are run.  Thus, you might say that you can dynamically decide
which asyncs are run for each occurence of the point in the program.

But I'd say it is fairly trivial to implement both schemes without
explicit support from the system.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel