0

I am looking for a better way to deal with asynchronous issues, currently I am using setTime out to rig race conditions but this seems like a bandage solution.

Here is an example of code I want to change

endTime = inputDuration
  setTimeout(function(){  edit((err) => {
    if (err) {
      return res.sendStatus(500)
    }
  },500)});

edit function takes in the parameters "startTime, endTime, and "name". The problem is endTime is created through a function which takes in an input and transforms it. this causes a race condition which makes it so that if endTime isn't produced fast enough, edit will fire first causing an undesirable outcome.

Ricky
  • 717
  • 3
  • 10
  • 21
  • 1
    Make the endTime function a promise, and fire the edit in the handler. https://developer.mozilla.org/nl/docs/Web/JavaScript/Reference/Global_Objects/Promise – Sjoerd de Wit Feb 07 '18 at 18:38
  • javascript is single threaded there is no race condition... its only in your logic... webworkers are different story – sumeet kumar Feb 07 '18 at 18:39
  • Yes, use [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) or [Observables](https://medium.com/@benlesh/learning-observable-by-building-observable-d5da57405d87). – msanford Feb 07 '18 at 18:39
  • 4
    Your example code makes no sense. I don't see a race condition, just an unexplained mess of nested function calls. – Patrick Roberts Feb 07 '18 at 18:39
  • 1
    @sumeetkumar single-threadedness doesn't eliminate race conditions: `setTimeout(console.log, Math.random() * 1000, 'foo'); setTimeout(console.log, Math.random() * 1000, 'bar');` What gets printed first? – Patrick Roberts Feb 07 '18 at 18:42
  • @PatrickRoberts i agree but its not because of threads its because of your logic official definition for race condition is https://support.microsoft.com/en-us/help/317723/description-of-race-conditions-and-deadlocks.. – sumeet kumar Feb 07 '18 at 19:05
  • @sumeet so in javascript when the second function fires before the first is finished processing should I just call it an asynchronous issue? – Ricky Feb 07 '18 at 19:21
  • We can say what is easy to convey here is another nice detailed discussion https://blog.raananweber.com/2015/06/17/no-there-are-no-race-conditions-in-javascript/ – sumeet kumar Feb 07 '18 at 19:44
  • @Ricky ignore sumeet. my example is called a "race condition." It doesn't matter if it's singlethreaded or not. – Patrick Roberts Feb 07 '18 at 19:46
  • @PatrickRoberts setTimeout(console.log, Math.random() * 1000, 'foo'); setTimeout(console.log, Math.random() * 1000, 'bar'); this is not race condition rather its intentional logic written to set the timeouts by developer with random value. – sumeet kumar Feb 07 '18 at 19:46
  • @sumeetkumar while I still assert that your "formal definition" does not comprehensively define what a race condition is, here is a single-threaded situation where "two tasks are operating on a shared resource": `var resource = 1; Promise.all([new Promise(resolve=>setTimeout(()=>{resource+=1;resolve()}, Math.random() * 1000)), new Promise(resolve=>setTimeout(()=>{resource*=2;resolve()}, Math.random() * 1000))]).then(()=>console.log(resource));` Now I ask you, is `resource == 3` or `resource == 4`? – Patrick Roberts Feb 07 '18 at 19:57
  • @sumeetkumar your argument that the example is contrived is irrelevant. It is representative of tasks that must occur asynchronously, such as fetching a value from a database, or reading a file from disk. – Patrick Roberts Feb 07 '18 at 20:00
  • @PatrickRoberts i agree to disagree but as i believe you have complete control what happens next unless your logic is on purpose have random behavior – sumeet kumar Feb 07 '18 at 20:28
  • @sumeetkumar same can be said about threaded race conditions. – Patrick Roberts Feb 07 '18 at 20:36

0 Answers0