New answers tagged

0

The documentation of any function or method using callbacks should describe how the callback will be used (unless it is obvious). For synchronous methods a callback is often executed while the method itself is still running, as part of the execution of the method. For asynchronous methods that return immediately, the callback will often be called long ...


0

The definition you give on the yellow background is meaningless and does not convey the meaning of a callback at all. A callback is just what the word implies, it calls back (to the caller/client/initiator). And its purpose is to allow the caller/client/initiator to respond to events that happen before the function it called has finished. A practical use is ...


3

Yes, if your "external" source is really other code run in a single threaded program (not at all uncommon, by the way), then the callback happens when the other code chooses to use it, such as visiting something. FWIW, Wikipedia says here: In computer programming, a callback is a piece of executable code that is passed as an argument to other code, ...


1

No, it does not assume concurrency. In fact, in JavaScript, there is no concurrency. At a very high level, the way systems that use events in a single threaded system might look roughly like this: while forever: if there are conditions that produce events add events to the event queue if there are events in the event queue ...


1

I think the problem is the same one as with any unintendend infinite recursion: You are not perfectly sure what the callee does when you call it, and if that callee happens to call the caller with unchanged arguments, you are doomed. I really don't think that your case is any different, only the involved mechanics differ. So, I would apply the same to your ...


0

I'm not 100% sure of the problem you had but it seems like you had issues with callbacks calling callbacks, or at least callbacks being called out of sequence. Why that was occurring seems to be that you are combining a callback-based architecture with an event based one, so you don't have full control over your program flow. A simple answer would be to ...


0

You make me feel old :-) IBM MQSeries was originally launched in 1992, and was primarily used on mainframe based systems. Java 1.0 was not released until 1996. I promise you that your application is not too old to talk to messaging systems. It may be that they don't wish to couple to a messaging system, but there is no way it is "too old". I have ...


0

Let's imagine that after doing each test, you had to analyze some data you recorded, and write those results out, and lets say that analysis is a somewhat computationally expensive operation and can't start until all the data is collected, while the configuration of the hardware and recording the data is cheap but it a lot of waiting. It could then make ...


1

Async/await is just syntactic sugar for using Tasks. In fact, async/await makes the code able to be more procedural rather than get caught in the callback pit. For instance, one (not great) way to run a task after another task would be: var task = StartSomething(); var continuation = task.ContinueWith(t => { var task2 = StartSomethingElse(t.Result); ...


0

I'd leave well enough alone. There is a time and place for sequential code and it sounds like you have a textbook example. Async/await are useful tools, but not the right tools for the problem you're solving. Put this another way, which code would be easier to maintain - your current code or code restructured to use async/await?



Top 50 recent answers are included