5 ms·

This reminds me a bit of how networking works on OS X and iOS (at least if you are using the "standard APIs" the way they are supposed to be used: The networkin

This reminds me a bit of how networking works on OS X and iOS (at least if you are using the "standard APIs" the way they are supposed to be used: The networking that is going on is tied to a runloop. Some apps tie the networking stuff to the main run loop. You can see which apps do that by simply opening a context menu in the app somewhere or open a regular menu from the app's main menu. The run loops will be "halted" for as long the menu is open and thus your networking will stop. As soon you dismiss the menu the networking will continue. At first this may seem totally bullshitty: Imagine a download manager. Do you really want the download to pause every time you open a context menu? Well it turns out it is not such a bad idea in many cases: What if the context menu allows you to cancel the download? If the download were to go on in the background you would have to explicitly take care of that. If you tie the networking callbacks to your main runloop this simply can't happen. Of course there are also a lot of use cases where you want your networking code to not have anything to do with your main runloop...

zbowling 13y ago
This isn't really correct. Runloops have modes. Often networking happens in a mode that is not restricted (see NSRunLoopCommonModes here https://developer.apple.com/library/ios/documentation/cocoa/reference/foundation/Classes/NSRunLoop_Class/Reference/Reference.html https://developer.apple.com/library/ios/documentation/cocoa/... ). If you are running your network code in default mode on the main thread (problematic doing that and it's probably better to use async methods these days) then yes that can happen but it's usually programmer error. On Mac, entering a modal window will usually put the runloop in a context that regular events won't fire and only those that mater to the modal window will fire. Commons mode almost always fires though. I work on Apportable (YC2011) and we have reimplemented CFRunLoop/NSRunLoop down to the bare metal. A lot of misconceptions on how it works we find.
- LinaLauneBaer 13y ago
  Thanks for the clarification. I am aware of what you mention in your answer. In my statement I simplified quite a bit. I know that runloops have different modes. What I was saying is that if you just use the "defaults" then you will see the phenomenon that I described. And I don't think that it is a programmer error if you use the defaults... but sure: These days you would probably just use a framework or take care of these details... May I know why you have reimplemented CFRunLoop?
  - zbowling 13y ago
    It almost always programmer error to use defaults mode for NSURLConnection, especially on Mac where they are more runloop modes used by the platform that are not inclusive of defaults mode, unless the user has a very specific reason. File IO is usually ok in defaults mode because it makes code easier and you don't have to worry about timeouts. We make Objective-C run on Android at Apportable :-) The entire stack. Everything from clang, GCD, CoreFoundation, Foundation, UIKit, and dozens of comm frameworks. It's fairly popular with game developers. We recently re-developed all of Foundation from scratch on top of the parts of CFLite that Apple open sources and no longer use GNUStep. http://docs.apportable.com/release-notes.html#1100 http://docs.apportable.com/release-notes.html#1100 We have even open sourced all our tests around Foundation as well and this is one of them. Check it out: https://github.com/apportable/FoundationTests https://github.com/apportable/FoundationTests
    - LinaLauneBaer 13y ago
      I still don't agree that it is programmer error per se... but we don't have to agree on that. :) Your idea is somewhat similar to "our" idea... at Objective-Cloud we try to bring Objective-C to the cloud... :) You try to bring it to Android. What a coincidence. Nice to meet you. :)
      - zbowling 13y ago
        We should talk off list. :-)
        LinaLauneBaer 13y ago
        :) My email address is in my profile in case you did not already find it...
  - weland 13y ago
    > And I don't think that it is a programmer error if you use the defaults... but sure: These days you would probably just use a framework or take care of these details... It's usually a programmer error when you write code that does something other than what you intend, regardless of whether or not what you intend to do is the default behaviour. I think this is perfectly understandable behaviour for a framework of such a general purpose. The whole convention over configuration thing works for tools like Ruby on Rails and web2py. 90% of the applications written using them are pretty much identical and the non-technical constraints favour quick delivery over well-adapted architecture, so you can afford making it obnoxiously hard for the rest of 10%.
marcosdumay 13y ago
MacOS had non-preemptive multitasking, what meant that a progam would only have a chance to transfer data once all other programs released the CPU. The default develoment suite also had several loops were it wouldn't release the CPU, there are some stories around about MacOS servers that stopped serving content because somebody left forcus on the wrong element, or left the mouse on a menu on some application. But both OS X and iOS are preemptive. Networking just keeps working, but your interface thread may stop for a while depending on how you write your programs.
- vidarh 13y ago
  That's not what he is saying. OS level networking keeps working. But an application that processes network events in the same context as it is processing UI events will cause its network related stuff to halt in some instances. That's not the OS's fault; that's "just" bad programmers, and just as trivial to do wrong on Linux or any other OS.

zbowling 13y ago

This isn't really correct. Runloops have modes. Often networking happens in a mode that is not restricted (see NSRunLoopCommonModes here https://developer.apple.com/library/ios/documentation/cocoa/reference/foundation/Classes/NSRunLoop_Class/Reference/Reference.html https://developer.apple.com/library/ios/documentation/cocoa/... ). If you are running your network code in default mode on the main thread (problematic doing that and it's probably better to use async methods these days) then yes that can happen but it's usually programmer error. On Mac, entering a modal window will usually put the runloop in a context that regular events won't fire and only those that mater to the modal window will fire. Commons mode almost always fires though. I work on Apportable (YC2011) and we have reimplemented CFRunLoop/NSRunLoop down to the bare metal. A lot of misconceptions on how it works we find.

LinaLauneBaer 13y ago
Thanks for the clarification. I am aware of what you mention in your answer. In my statement I simplified quite a bit. I know that runloops have different modes. What I was saying is that if you just use the "defaults" then you will see the phenomenon that I described. And I don't think that it is a programmer error if you use the defaults... but sure: These days you would probably just use a framework or take care of these details... May I know why you have reimplemented CFRunLoop?
- zbowling 13y ago
  It almost always programmer error to use defaults mode for NSURLConnection, especially on Mac where they are more runloop modes used by the platform that are not inclusive of defaults mode, unless the user has a very specific reason. File IO is usually ok in defaults mode because it makes code easier and you don't have to worry about timeouts. We make Objective-C run on Android at Apportable :-) The entire stack. Everything from clang, GCD, CoreFoundation, Foundation, UIKit, and dozens of comm frameworks. It's fairly popular with game developers. We recently re-developed all of Foundation from scratch on top of the parts of CFLite that Apple open sources and no longer use GNUStep. http://docs.apportable.com/release-notes.html#1100 http://docs.apportable.com/release-notes.html#1100 We have even open sourced all our tests around Foundation as well and this is one of them. Check it out: https://github.com/apportable/FoundationTests https://github.com/apportable/FoundationTests
  - LinaLauneBaer 13y ago
    I still don't agree that it is programmer error per se... but we don't have to agree on that. :) Your idea is somewhat similar to "our" idea... at Objective-Cloud we try to bring Objective-C to the cloud... :) You try to bring it to Android. What a coincidence. Nice to meet you. :)
    - zbowling 13y ago
      We should talk off list. :-)
      - LinaLauneBaer 13y ago
        :) My email address is in my profile in case you did not already find it...
- weland 13y ago
  > And I don't think that it is a programmer error if you use the defaults... but sure: These days you would probably just use a framework or take care of these details... It's usually a programmer error when you write code that does something other than what you intend, regardless of whether or not what you intend to do is the default behaviour. I think this is perfectly understandable behaviour for a framework of such a general purpose. The whole convention over configuration thing works for tools like Ruby on Rails and web2py. 90% of the applications written using them are pretty much identical and the non-technical constraints favour quick delivery over well-adapted architecture, so you can afford making it obnoxiously hard for the rest of 10%.

marcosdumay 13y ago

MacOS had non-preemptive multitasking, what meant that a progam would only have a chance to transfer data once all other programs released the CPU. The default develoment suite also had several loops were it wouldn't release the CPU, there are some stories around about MacOS servers that stopped serving content because somebody left forcus on the wrong element, or left the mouse on a menu on some application. But both OS X and iOS are preemptive. Networking just keeps working, but your interface thread may stop for a while depending on how you write your programs.

vidarh 13y ago
That's not what he is saying. OS level networking keeps working. But an application that processes network events in the same context as it is processing UI events will cause its network related stuff to halt in some instances. That's not the OS's fault; that's "just" bad programmers, and just as trivial to do wrong on Linux or any other OS.