Re: Understanding callbacks

Ignore this. I completely missed the point (asynchronous). Sorry. I'll update later when I've eaten.

Think about grep.

Grep is a generic routine that filters one list (which may come from an array) into another list (which may be assigned to an array).

The callback defines how it filters the list.

So, with no changes to the implementation of grep, this filters out even numbers: my @odds = grep{ ( $_ % 2 ) == 1 } 1 .. 100;

and this filters out the odd numbers: my @evens = grep{ ( $_ % 2 ) == 0 } 1 .. 100;

The callbacks: { ... }, allow a generic routine to perform multiple purposes.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Comment on Re: Understanding callbacks Select or Download Code

Replies are listed 'Best First'.
Re^2: Understanding callbacks by stevieb (Canon) on Jun 13, 2015 at 15:21 UTC
This is a good example which is easy to understand, thanks. However, this appears to be a 'blocking' callback. I'm really hoping for an example of a 'non-blocking' one. Or is it I'm just misinterpreting the terminology here?	[reply]
Re^3: Understanding callbacks by davido (Cardinal) on Jun 13, 2015 at 15:37 UTC
The problem is that your callback is blocking too. It sleeps for one second, during which time nothing else can happen. An event loop will typically have listeners registered with it. When a listener hears a message that is of interest to it, the callback will be invoked. If the callback is doing work that might consume a lot of time, that callback itself may need to break its work into smaller chunks that can be registered with the event loop too, or may need to fork a process. Or both perhaps. Take the example of asynchronous web apps. You may have an app that listens for http requests. So that listener sits in the event loop waiting for something to happen. When a request comes in, the listener decides if the request is interesting to it (for example, did we get a get request with a useful path?). If so, it fires off the callback associated with the specific get request (this may be handled by a route, in mojolicious). Now maybe that get request handler needs to scrape info from example.com. The get request handler could hit the remote server and wait, during which time the application blocks. Or it could fire off a request, and then install a listener in the event loop to listen for the response from the remote server. At that point the get request handler is free to return control back to the main event loop. Now the main event loop continues listening for get requests, but is also listening for a response from the remote server. And when that response comes, another callback can be fired off, possibly to render the scraped content. So asynchronous apps that use an event loop usually have to be designed at every level to not block; to listen, react, and register callbacks that respond to events. Callbacks may still set up listeners, and may themselves install callbacks to happen. Dave	[reply]