0

My background is primarily as a server dev and manager but I have to get in and do work in front-end and iOS dev. I'm asking this question not to be argumetative but I really don't get what is meant by the single threaded nature of Javascript in terms of network requests.

I understand how events get registered in Javascript and iOS at the userspace level. My question is that the UI in iOS will block if a network request is not put on a background thread. However, in a browser / javascript runtime, it won't. Javascript (at least current implementations / pre-web-workers) is ALWAYS described as single-threaded. I understand (I think - but this could be the problem) the way that setInterval is used to check for completion but how could the single-threaded Javascript runtime have async functions that don't block the UI (especially in light of iOS not having it)? For example, in this answer, it would seem that 5 thread would need to be created: Parallel asynchronous Ajax requests using jQuery

In fact, one could have 6 outbound network requests at once. When the javascript runtime is described as single-threaded, does this mean something fundamentally different than the iOS notion of multithreading (or probably more accurately the POSIX notion of a while loop with pthread_create for handling a socket descriptor).

I'm probably just not getting something but I think most of the examples provided don't get at how this is actually done in a single threaded environment (unless the network request is considered at the OS level and not the Javascript runtime level)

thx for any help on this

Community
  • 1
  • 1
timpone
  • 19,235
  • 36
  • 121
  • 211
  • I don't think it's a duplicate of that question specifically something different is meant by threading when the Javascript runtime is said to be single threaded vs POSIX or iOS. It seems that network requests are considered part of the OS rather than userspace as they are in iOS and POSIX. – timpone Aug 20 '13 at 18:47

2 Answers2

1

Consider reading this SO: How does non blocking IO work in javascript

What it mentions is that javascript is eventloop based which means that when you build a asynchronus http-request. It will do the ajax-call, register an eventlistener (to do the callback method) and then continue do the rest of the work it got queued. When the response comes back the listener will fire the callback-method that you have registered.

Community
  • 1
  • 1
Nils Larson
  • 488
  • 4
  • 14
  • thx for response but node.js will most certainly create threads in libraries even though the main app is single threaded. I am kinda assuming that this is the browser model - I'm surprised that most sources / documentation don't just say that. – timpone Aug 20 '13 at 19:06
  • @timpone "node.js will most certainly create threads in libraries" - do you have any actual reason for saying that? Node itself does create extra threads (well, v8 does - javascript parsing and optimization are done on them). However, I don't think that there are any node libraries that silently create new threads. – Aaron Dufour Aug 20 '13 at 21:16
  • the main event loop is certainly single threaded but it will create a pool of worker threads. See the answer here: http://stackoverflow.com/questions/10680601/nodejs-event-loop That's a bit why I asked around pthread_create or iOS blocks which will create new threads in the original question. – timpone Aug 20 '13 at 21:37
0

In the programming model for a web app, execution is not pre-empted to allow another thread to run. A thread of your webapp runs until it yields, either by returning to its origin or making an i/o request. Say you have a click listener -- it won't interrupt other code that's running in your app; the browser runs it after all the events ahead of it have run to completion. In a browser app, you don't need to serialize access to data because only one stack is active at any given time. Hth.

fred02138
  • 3,323
  • 1
  • 14
  • 17