Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #127708 > unrolled thread

Callbacks are an abomination

Back to article view | Back to comp.lang.c

Contents

  Callbacks are an abomination Chad <cdalten@gmail.com> - 2018-03-12 14:00 -0700
    Re: Callbacks are an abomination Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-12 15:06 -0600
      Re: Callbacks are an abomination Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-12 21:42 +0000
        Re: Callbacks are an abomination "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 14:51 -0700
        Re: Callbacks are an abomination Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-12 17:39 -0600
          Re: Callbacks are an abomination Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-13 07:11 +0000
            Re: Callbacks are an abomination Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-03-13 11:57 +0300
              Re: Callbacks are an abomination Chad <cdalten@gmail.com> - 2018-03-13 03:09 -0700
              Re: Callbacks are an abomination Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-13 14:20 +0000
      Re: Callbacks are an abomination Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-03-13 14:41 +0300
        Re: Callbacks are an abomination Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-13 13:45 -0600
        Re: Callbacks are an abomination Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 09:05 -0700
          Re: Callbacks are an abomination Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-03-19 11:47 +0300
          Re: Callbacks are an abomination Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 22:04 -0700
    Re: Callbacks are an abomination Thiago Adams <thiago.adams@gmail.com> - 2018-03-12 16:23 -0700
      Re: Callbacks are an abomination Ian Collins <ian-news@hotmail.com> - 2018-03-13 12:27 +1300
      Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-13 14:52 -0700
        Re: Callbacks are an abomination jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-14 00:26 +0100
          Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-13 18:33 -0700
            Re: Callbacks are an abomination Robert Wessel <robertwessel2@yahoo.com> - 2018-03-14 00:14 -0500
              Re: Callbacks are an abomination "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-13 22:57 -0700
              Re: Callbacks are an abomination already5chosen@yahoo.com - 2018-03-14 02:08 -0700
                Re: Callbacks are an abomination "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-19 21:46 -0700
          Re: Callbacks are an abomination Melzzzzz <Melzzzzz@zzzzz.com> - 2018-03-14 03:38 +0000
        Re: Callbacks are an abomination Thiago Adams <thiago.adams@gmail.com> - 2018-03-13 17:31 -0700
        Re: Callbacks are an abomination already5chosen@yahoo.com - 2018-03-14 02:20 -0700
          Re: Callbacks are an abomination Chad <cdalten@gmail.com> - 2018-03-14 04:38 -0700
            Re: Callbacks are an abomination Wouter Verhelst <w@uter.be> - 2018-03-14 12:47 +0100
              Re: Callbacks are an abomination Chad <cdalten@gmail.com> - 2018-03-15 14:37 -0700
            Re: Callbacks are an abomination Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-14 11:59 +0000
              Re: Callbacks are an abomination Chad <cdalten@gmail.com> - 2018-03-15 14:36 -0700
          Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-14 16:07 -0700
    Re: Callbacks are an abomination jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-13 16:25 +0100
    Re: Callbacks are an abomination "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-03-14 05:22 -0700
      Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-14 17:14 -0700
        Re: Callbacks are an abomination jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-15 02:14 +0100
          Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-14 21:11 -0700
        Re: Callbacks are an abomination already5chosen@yahoo.com - 2018-03-15 03:51 -0700
          Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-15 04:52 -0700
        Re: Callbacks are an abomination "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-03-15 05:04 -0700
          Re: Callbacks are an abomination William Ahern <william@25thandClement.com> - 2018-03-15 14:57 -0700
            Re: Callbacks are an abomination "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-03-15 17:02 -0700

Page 1 of 3  [1] 2 3  Next page →

#127708 — Callbacks are an abomination

I'm currently writing some custom http code for my job. And for whatever reasons, the engineers that wrote the APIs that I'm forced to use, like, uhh...seem to have get a hardon over both callbacks and handlers.

Seriously.

I haven't seen this much fuckery since having to endure writing GTK for Linux.

[toc] | [next] | [standalone]

#127709

Chad <cdalten@gmail.com> writes:

> I'm currently writing some custom http code for my job. And for
> whatever reasons, the engineers that wrote the APIs that I'm forced to
> use, like, uhh...seem to have get a hardon over both callbacks and
> handlers.
>
> Seriously.
>
> I haven't seen this much fuckery since having to endure writing GTK for Linux.

The choices are pretty much that or writing your own event loop.  Having
done both, I'll take the callbacks.

[toc] | [prev] | [next] | [standalone]

#127711

On Mon, 2018-03-12, Joe Pfeiffer wrote:
> Chad <cdalten@gmail.com> writes:
>
>> I'm currently writing some custom http code for my job. And for
>> whatever reasons, the engineers that wrote the APIs that I'm forced to
>> use, like, uhh...seem to have get a hardon over both callbacks and
>> handlers.
>>
>> Seriously.
>>
>> I haven't seen this much fuckery since having to endure writing GTK for Linux.
>
> The choices are pretty much that or writing your own event loop.  Having
> done both, I'll take the callbacks.

I'd prefer having control over the event loop, in case I need to do
anything else except servicing that HTTP API.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#127712

On 3/12/2018 2:42 PM, Jorgen Grahn wrote:
> On Mon, 2018-03-12, Joe Pfeiffer wrote:
>> Chad <cdalten@gmail.com> writes:
>>
>>> I'm currently writing some custom http code for my job. And for
>>> whatever reasons, the engineers that wrote the APIs that I'm forced to
>>> use, like, uhh...seem to have get a hardon over both callbacks and
>>> handlers.
>>>
>>> Seriously.
>>>
>>> I haven't seen this much fuckery since having to endure writing GTK for Linux.
>>
>> The choices are pretty much that or writing your own event loop.  Having
>> done both, I'll take the callbacks.
> 
> I'd prefer having control over the event loop, in case I need to do
> anything else except servicing that HTTP API.

Agreed. I also like having full control of creating the event loop and 
dispatching events. Fwiw, I had to make the following diagram a while 
back for a little project:

http://webpages.charter.net/appcore/vzoom/msgsys.pdf

[toc] | [prev] | [next] | [standalone]

#127724

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Mon, 2018-03-12, Joe Pfeiffer wrote:
>> Chad <cdalten@gmail.com> writes:
>>
>>> I'm currently writing some custom http code for my job. And for
>>> whatever reasons, the engineers that wrote the APIs that I'm forced to
>>> use, like, uhh...seem to have get a hardon over both callbacks and
>>> handlers.
>>>
>>> Seriously.
>>>
>>> I haven't seen this much fuckery since having to endure writing GTK for Linux.
>>
>> The choices are pretty much that or writing your own event loop.  Having
>> done both, I'll take the callbacks.
>
> I'd prefer having control over the event loop, in case I need to do
> anything else except servicing that HTTP API.

Every callback-based API I've ever used in which I might want to do
something when there were no events pending had a provision for
dispatching a "no event" event.

[toc] | [prev] | [next] | [standalone]

#127731

On Mon, 2018-03-12, Joe Pfeiffer wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Mon, 2018-03-12, Joe Pfeiffer wrote:
>>> Chad <cdalten@gmail.com> writes:
>>>
>>>> I'm currently writing some custom http code for my job. And for
>>>> whatever reasons, the engineers that wrote the APIs that I'm forced to
>>>> use, like, uhh...seem to have get a hardon over both callbacks and
>>>> handlers.
>>>>
>>>> Seriously.
>>>>
>>>> I haven't seen this much fuckery since having to endure writing GTK for Linux.
>>>
>>> The choices are pretty much that or writing your own event loop.  Having
>>> done both, I'll take the callbacks.
>>
>> I'd prefer having control over the event loop, in case I need to do
>> anything else except servicing that HTTP API.
>
> Every callback-based API I've ever used in which I might want to do
> something when there were no events pending had a provision for
> dispatching a "no event" event.

I should explain that with "do something else except" I mean what Unix
select()/poll() provides: act on state changes for file descriptors
and on timeouts.

But yes, my experience with callback APIs may be limited to the very
worst ones.  The ones I've used have frequently not even allowed
passing a user-provided void* for context.

Can you show an example of a good one?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#127733

Jorgen Grahn:

>But yes, my experience with callback APIs may be limited to
>the very worst ones.  The ones I've used have frequently
>not even allowed passing a user-provided void* for context.
>
>Can you show an example of a good one?

How about these:

  https://wiki.gnome.org/Projects/GLib
  (see tree traversal for example)
  https://sourceforge.net/projects/libxc/

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#127737

I think the closest I've come to a void* context is by passing null (ie, not NULL) as the first argument to the function.

[toc] | [prev] | [next] | [standalone]

#127743

On Tue, 2018-03-13, Anton Shepelev wrote:
> Jorgen Grahn:
>
>>But yes, my experience with callback APIs may be limited to
>>the very worst ones.  The ones I've used have frequently
>>not even allowed passing a user-provided void* for context.
>>
>>Can you show an example of a good one?
>
> How about these:
>
>   https://wiki.gnome.org/Projects/GLib
>   (see tree traversal for example)
>   https://sourceforge.net/projects/libxc/

Ok, thanks.  My concern was more about callbacks for blocking I/O,
such as the pcap_loop() construct of libpcap.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#127740

Joe Pfeiffer to Chad:

>>I'm currently writing some custom http code for my job.
>>And for whatever reasons, the engineers that wrote the
>>APIs that I'm forced to use, like, uhh...seem to have get
>>a hardon over both callbacks and handlers.
>>
>>Seriously.
>>
>>I haven't seen this much fuckery since having to endure
>>writing GTK for Linux.
>
>The choices are pretty much that or writing your own event
>loop.  Having done both, I'll take the callbacks.

Will you not then have to implement your own callback
interface to let the users subscribe to your events?  Or did
you mean manual dispatch of hard-coded events?

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#127765

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Joe Pfeiffer to Chad:
>
>>>I'm currently writing some custom http code for my job.
>>>And for whatever reasons, the engineers that wrote the
>>>APIs that I'm forced to use, like, uhh...seem to have get
>>>a hardon over both callbacks and handlers.
>>>
>>>Seriously.
>>>
>>>I haven't seen this much fuckery since having to endure
>>>writing GTK for Linux.
>>
>>The choices are pretty much that or writing your own event
>>loop.  Having done both, I'll take the callbacks.
>
> Will you not then have to implement your own callback
> interface to let the users subscribe to your events?  Or did
> you mean manual dispatch of hard-coded events?

Depends on the extent to which you're providing an API vs writing an
application, and how big.  But yes, somewhere in that spectrum.  And as
I may not have made clear, I'll definitely take a callback API that's
provided to me.

[toc] | [prev] | [next] | [standalone]

#127942

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Joe Pfeiffer to Chad:
>
>>> I'm currently writing some custom http code for my job.
>>> And for whatever reasons, the engineers that wrote the
>>> APIs that I'm forced to use, like, uhh...seem to have get
>>> a hardon over both callbacks and handlers.
>>>
>>> Seriously.
>>>
>>> I haven't seen this much fuckery since having to endure
>>> writing GTK for Linux.
>>
>> The choices are pretty much that or writing your own event
>> loop.  Having done both, I'll take the callbacks.
>
> Will you not then have to implement your own callback
> interface to let the users subscribe to your events?  Or did
> you mean manual dispatch of hard-coded events?

I see you have revised your newsgroup formatting style.  Noted
and duly appreciated.

[toc] | [prev] | [next] | [standalone]

#127989

Tim Rentsch to Anton Shepelev:

>>Will you not then have to implement your own callback
>>interface to let the users subscribe to your events?  Or
>>did you mean manual dispatch of hard-coded events?
>
>I see you have revised your newsgroup formatting style.
>Noted and duly appreciated.

Thank you.  So far I have done it for this newsgroup only.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#128074

On Saturday, March 17, 2018 at 9:05:21 AM UTC-7, Tim Rentsch wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> 
> > Joe Pfeiffer to Chad:
> >
> >>> I'm currently writing some custom http code for my job.
> >>> And for whatever reasons, the engineers that wrote the
> >>> APIs that I'm forced to use, like, uhh...seem to have get
> >>> a hardon over both callbacks and handlers.
> >>>
> >>> Seriously.
> >>>
> >>> I haven't seen this much fuckery since having to endure
> >>> writing GTK for Linux.
> >>
> >> The choices are pretty much that or writing your own event
> >> loop.  Having done both, I'll take the callbacks.
> >
> > Will you not then have to implement your own callback
> > interface to let the users subscribe to your events?  Or did
> > you mean manual dispatch of hard-coded events?
> 
> I see you have revised your newsgroup formatting style.  Noted
> and duly appreciated.



Of course I quoted examples of Peter 'The Flooder' Kohlmann flooding every group I post to, blaming me for the actions of others, etc. His response: to claim I am Peter 'The Flooder' Kohlmann. 

The herd members value the lowest common denominator in both their lives and their computer systems. His remarkable "diagnostic proficiency" distracted him from a component he insists does not exists that everyone else is already using with this software. The only thing defective here is Peter 'The Flooder' Kohlmann. How long has this debate been going on? Now that nobody is speaking to Peter 'The Flooder' Kohlmann, he's making it sound like he's figured out the right timing -- when in fact, people are just not playing his game anymore. How is GIMP on Linux doing anything above the lowest common denominator? 



--
"You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention"
Steve Carroll, making the dumbest comment ever uttered.

[toc] | [prev] | [next] | [standalone]

#127719

On Monday, March 12, 2018 at 6:00:39 PM UTC-3, Chad wrote:
> I'm currently writing some custom http code for my job. And for whatever reasons, the engineers that wrote the APIs that I'm forced to use, like, uhh...seem to have get a hardon over both callbacks and handlers.
> 
> Seriously.
> 
> I haven't seen this much fuckery since having to endure writing GTK for Linux.

I disagree. How do you do asynchronous code?
Callbacks are useful to decouple code and they are
compousable.  An async task  completation  
call a closure (function pointer + data) some code 
that the caller doesnt know about.

Some alternatives uses state machine that are very 
coupled solution.


With this decoupling the same async function
can be used to answer an http request for instance 
or used internally in a async fashion without to have
to write 2 state machines.
 
I am curious why so many people disagree on that.

[toc] | [prev] | [next] | [standalone]

#127723

On 03/13/2018 12:23 PM, Thiago Adams wrote:
> 
> With this decoupling the same async function
> can be used to answer an http request for instance
> or used internally in a async fashion without to have
> to write 2 state machines.
>   
> I am curious why so many people disagree on that.

Not many do!

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#127782

Thiago Adams <thiago.adams@gmail.com> wrote:
> On Monday, March 12, 2018 at 6:00:39 PM UTC-3, Chad wrote:
>> I'm currently writing some custom http code for my job. And for whatever reasons, the engineers that wrote the APIs that I'm forced to use, like, uhh...seem to have get a hardon over both callbacks and handlers.
>> 
>> Seriously.
>> 
>> I haven't seen this much fuckery since having to endure writing GTK for Linux.
> 
> I disagree. How do you do asynchronous code?

Poorly? Angrily?

> Callbacks are useful to decouple code and they are
> compousable.

Composable compared to what? If they're so composable, try turning every
function in your application into a function which takes a continuation
(i.e. function pointer and state). It'd be a nightmare.

A programming language is *supposed* to hide this from you. The stack is
literally a list of continuations--address to call back to plus a data store
for function state--except you normally don't realize this because the
compiler and hardware does its magic.

Asynchronous callbacks are a giant step backwards. You're manually and
meticulously managing your own call state, a chore so odious yet easily
susceptible to automation that it's one of the primary functions of almost
every language conceived in over 50 years; something that is even heavily
optimized in hardware. Not only that, but it's now so well hidden that
people don't even realize it's being automated. So well hidden, in fact,
that language designers hid it too well, and now in the age of highly
concurrent network programming language designers and programmers alike are
ignorantly recapitulating the evolution of stack management that occured
over 50 years ago; they've yet to appreciate the fundamental task and the
obvious solution staring them right in the face.

Admittedly, in C there's not much choice when you're writing
high-performance network services as C doesn't provide primitives that fully
encapsulate the stack as a first-class object. Threads are closest but they
still hide the process of scheduling. Stackful, asymmetric coroutines (aka
fibers + asymmetric resume/yield interfaces) is the ideal construct (most of
the power of callcc with a tiny fraction of the complexity and cost) that
elegantly bridges explicitly stack management with implicit function calling
conventions, but for historical reasons those are difficult to implement in
a manner backwards compatible with existing C calling conventions. So the
only language implementations that provide such constructs are those which
manage their own stack constructs independent from the OS-native
conventions. Erlang, Go, Lua, and Scheme are notable examples which
understand this, and one of the defining characteristics of each language,
unsurprisingly, is how well they support highly-concurrent programming, and
moreover how truly composable it can be (no specialized "asychronous"
libraries or second-class calling conventions required except for leaf
functions, which bind to blocking system calls). Python and JavaScript are
classic examples of the contortions language designers are forced to go
through once implementations have hitched their wagon to the limitations of
OS-native stack management.

Many languages wedded to existing C calling conventions are moving to
async/await, but if you know anything about how that's implemented it's
obvious what's happening, obvious where the *real* deficiency lies, and
obvious why the performance (time and memory) is actually subpar compared to
what it theoretically could be.

> An async task  completation call a closure (function pointer + data) some
> code that the caller doesnt know about.
> 
> Some alternatives uses state machine that are very 
> coupled solution.
> 
> 
> With this decoupling the same async function
> can be used to answer an http request for instance 
> or used internally in a async fashion without to have
> to write 2 state machines.
>  
> I am curious why so many people disagree on that.

Everything good about callbacks derives from the fact that they're nominally
functions. Everything bad about callbacks derives from the fact that they're
functions which violate the conventional call-wait-return semantics. You can
do high-performance asynchronous programming using call-wait-return
semantics, just not in C or any language which implicitly relies on typical,
OS-native stack management.

[toc] | [prev] | [next] | [standalone]

#127786

Le 13/03/2018 à 22:52, William Ahern a écrit :
> Asynchronous callbacks are a giant step backwards.

Event oriented programming is about ... well, events.

The user pressed the OK button, for instance.

The programmer decides in the callback mechanism, what is to be done 
when that event happens.

Event oriented programming is about handling events. And they have to be 
handled by the programmer... I hope you will not take your exaggerations 
that far.

Without asynchronous callbacks you can't handle asynchronous events. 
What should happen when the user presses the OK button?

Nothing?

Something?

That's an asynchronous event. Event oriented programming is based on 
that. Handling events. And please, I do not see how would you do that in 
a reasonable way without asynchronous callbacks.

The machine has to react to that event. A window should be closed, and a 
series of events should start. Reading the info in the dialog box, 
testing it for correctness, and then starting a series of other events: 
fetch the connection, send the data to the database or waiting for the 
result of a query or whatever.

Events. Asynchronous events.

This is organized through callbacks, i.e. specifications for the machine 
reaction to some exterior event:

ASYNCHRONOUS.

That's why you use asynchronous callbacks.

[toc] | [prev] | [next] | [standalone]

#127790

In article <p89mmn$15r$1@dont-email.me> you wrote:
> Le 13/03/2018 à 22:52, William Ahern a écrit :
>> Asynchronous callbacks are a giant step backwards.
> 
> Event oriented programming is about ... well, events.
> 
> The user pressed the OK button, for instance.
> 
> The programmer decides in the callback mechanism, what is to be done 
> when that event happens.
> 
> Event oriented programming is about handling events. And they have to be 
> handled by the programmer... I hope you will not take your exaggerations 
> that far.
> 
> Without asynchronous callbacks you can't handle asynchronous events. 

Huh? Every piece of software handles asynchronous events. Invoking software
is asynchronous. Reading a file is asynchronous as it either needs to be
read from disk, paged into memory, or copied across the cache hierarchy.

Basically everything software does is asynchronous. *How* asynchrony is
modeled both across and *within* languages varies. _Usually_ it's hidden
behind a facade of sequential processing, where waiting for data appears to
happen instantaneous and there's a single logical flow of execution. But not
always, and a rarely to the exclusion of other mechanisms.

Have you ever wondered where signals came from? Many years ago there were
intense debates about how to best model the signaling of concurrent events:
as interrupts or via a queuing and polling mechanism. Guess which camp
devised the signal API?

Asynchronous callbacks are cousins to signals, and pose almost all the same
usability and composability problems.

> What should happen when the user presses the OK button?
> 
> Nothing?
> 
> Something?
> 
> That's an asynchronous event. Event oriented programming is based on 
> that. Handling events. And please, I do not see how would you do that in 
> a reasonable way without asynchronous callbacks.

When a user presses an OK button does the OS invoke an asynchronous callback
withn the application? On Windows, yes, as Windows largely adopted the
interrupt model of event notification. In the Unix ecosystem, no; such
events are queued and polled (blocking or non-blocking).

That doesn't mean Unix software cannot be highly concurrent. How that model
is subsequently expressed in a programming language is another matter. In a
language like Erlang or Go, regardless of the OS model, the _language_ model
is to have one logical thread (by thread I mean a logical flow of execution
which an independent call stack, but this needn't be a "kernel" thread) per
event source where execution is suspended while waiting to dequeue the next
event. In C on Unix, even though the OS enqueues events for the application
to consume, because it's not ergonomic to have one logical execution thread
per event, you have to use asynchronous callbacks.

> The machine has to react to that event. A window should be closed, and a 
> series of events should start. Reading the info in the dialog box, 
> testing it for correctness, and then starting a series of other events: 
> fetch the connection, send the data to the database or waiting for the 
> result of a query or whatever.
> 
> Events. Asynchronous events.
> 
> This is organized through callbacks, i.e. specifications for the machine 
> reaction to some exterior event:
> 
> ASYNCHRONOUS.
> 
> That's why you use asynchronous callbacks.

Again, modern languages and environments do such a wonderful job of hiding
asynchronicity that people are oblivous to the *obvious* alternatives to
callbacks and explicit management of call state. Worse than oblivious,
people don't even grasp the underlying equivalencies which means they don't
truly possess a proper mental model of asynchronous callbacks and program
execution flow.

Go back to what I said earlier concerning the C call stack, and how the
return address and stack objects constitute continuations--in other words,
just like a callback + cookie (function address plus function invocation
state).

Process, threads, fibers, callbacks... people miss the forest for the trees.
Those concepts evoke overly technical implementation details like virtual
addressing and multi-CPU parallelism. Instead, travel back in time 50 years
and imagine what those words and concepts meant to early language designers
who were figuring how to design software systems which needed to process a
multitude of concurrent events in the most elegant, more natural way
possible. The solutions they came up with for solving the problem of
asynchronous event in an elegant manner, performant, and _composable_ manner
are right under your nose.

[toc] | [prev] | [next] | [standalone]

#127792

On Tue, 13 Mar 2018 18:33:54 -0700, William Ahern
<william@25thandClement.com> wrote:


>When a user presses an OK button does the OS invoke an asynchronous callback
>withn the application? On Windows, yes, as Windows largely adopted the
>interrupt model of event notification. In the Unix ecosystem, no; such
>events are queued and polled (blocking or non-blocking).


Windows messages are anything but asynchronous.  They might get
generated asynchronously, but they're queued, and then processed as
the receiving application polls that queue, via the (in)famous Windows
message loop.

Now there are asynchronous callbacks in Windows, but they're not
usually related to things like the user clicking a button.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web