Re: [OT] Sync vs ASync Server Comms

2013-03-11 Thread Dave
On 25 Feb 2013, at 22:45, Steve Sisak wrote: At 3:18 PM + 2/25/13, Dave wrote: On 25 Feb 2013, at 13:57, Steve Sisak wrote: Created A, B, C, make C dependent on A, B, submit all of them to an NSOperationQueue and wait for C to complete (or put your completion code on a block dependent

Re: [OT] Sync vs ASync Server Comms

2013-03-11 Thread Dave
On 25 Feb 2013, at 15:45, Kyle Sluder wrote: On Mon, Feb 25, 2013, at 07:18 AM, Dave wrote: Agreed. but that is true of anything, I am comfortable with Multi- Threading so it's not really an issue for me. Someone who's truly comfortable with multithreading would be relishing the opportunity

Re: [OT] Sync vs ASync Server Comms

2013-02-27 Thread Ten Horses | Diederik Meijer
On iOS sync will freeze your user interface for the duration of the network call, because it is done on the main thread, async is done in the background and keeps the interface responsive, you can then update your data when done Dave schreef op 2013-02-22 11:13: > Hi All, > > I was readin

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Kyle Sluder
On Mon, Feb 25, 2013, at 02:45 PM, Steve Sisak wrote: > > The current trend is away from threads and toward asynchronous > programming. > > That's orthogonal to whether your tasks are run on a single > (XXRunLoop) or multiple (GCD) threads -- the advantage of GCD is that > the system gets do de

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Steve Sisak
At 3:18 PM + 2/25/13, Dave wrote: On 25 Feb 2013, at 13:57, Steve Sisak wrote: Created A, B, C, make C dependent on A, B, submit all of them to an NSOperationQueue and wait for C to complete (or put your completion code on a block dependent on C -- NSBlockOperation makes this really easy.

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Kyle Sluder
On Mon, Feb 25, 2013, at 07:18 AM, Dave wrote: > Agreed. but that is true of anything, I am comfortable with Multi- > Threading so it's not really an issue for me. Someone who's truly comfortable with multithreading would be relishing the opportunity to not use it. --Kyle Sluder

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Dave
On 25 Feb 2013, at 13:57, Steve Sisak wrote: At 12:26 PM + 2/24/13, Dave wrote: I think I see what you mean, but I'd argue that there are still "threading" issues, the OS will create the Background Threads and take care of calling you back on the main thread, I agree, and, if that's a

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Steve Sisak
At 12:26 PM + 2/24/13, Dave wrote: I think I see what you mean, but I'd argue that there are still "threading" issues, the OS will create the Background Threads and take care of calling you back on the main thread, I agree, and, if that's all you were doing, it might be said to have "No Thr

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Uli Kusterer
Generally, using 4 exclamation marks in a sentence (or three question marks, come to think of it) is considered "yelling". Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de On Feb 22, 2013, at 8:32 AM, Dave wrote: > Of course there are threading "issue

Re: [OT] Sync vs ASync Server Comms

2013-02-25 Thread Dave
On 22 Feb 2013, at 18:18, Quincey Morris wrote: On Feb 22, 2013, at 08:32 , Dave wrote: As long as you are not running on the main thread there is no real difference between a Sync or ASync operation as far as any of the issues you mention above are concerned. You're correct that, at so

Re: [OT] Sync vs ASync Server Comms

2013-02-24 Thread Mike Abdullah
On 24 Feb 2013, at 12:26, Dave wrote: > Hi All, > > On 22 Feb 2013, at 22:23, Jens Alfke wrote: > >> >> On Feb 22, 2013, at 8:32 AM, Dave wrote: >> >>> Of course there are threading "issues" Having delegates doesn't stop >>> that >> >> There are no threading issues if you don’t create

Re: [OT] Sync vs ASync Server Comms

2013-02-24 Thread Dave
Hi All, On 22 Feb 2013, at 22:23, Jens Alfke wrote: On Feb 22, 2013, at 8:32 AM, Dave wrote: Of course there are threading "issues" Having delegates doesn't stop that There are no threading issues if you don’t create background threads. I’ve written a lot of code that does network

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Jens Alfke
On Feb 22, 2013, at 8:32 AM, Dave wrote: > Of course there are threading "issues" Having delegates doesn't stop that There are no threading issues if you don’t create background threads. I’ve written a lot of code that does network access using the async APIs, and most of it didn’t requir

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Quincey Morris
On Feb 22, 2013, at 08:32 , Dave wrote: > As long as you are not running on the main thread there is no real difference > between a Sync or ASync operation as far as any of the issues you mention > above are concerned. You're correct that, at some level, using synchronous methods on a backgrou

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Alex Zavatone
Well, one reason on iOS is that it will happen on thread 1 and block the main thread which is also the thread that the GUI is handled on. Sent from my iPad On Feb 22, 2013, at 5:13 AM, Dave wrote: > Hi All, > > I was reading an article about Server/Client communications using a Rest > servic

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Dave
On 22 Feb 2013, at 15:48, Fritz Anderson wrote: On 22 Feb 2013, at 8:56 AM, Dave wrote: A (Background) thread has two choices at this stage: 1. Call aSyncComputePIToAZillionPlacesWithDelegate and provide a delegate that will be called back with the result. 2. Call syncComputePIToAZill

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Fritz Anderson
On 22 Feb 2013, at 8:56 AM, Dave wrote: > A (Background) thread has two choices at this stage: > > 1. Call aSyncComputePIToAZillionPlacesWithDelegate and provide a delegate > that will be called back with the result. > > 2. Call syncComputePIToAZillionPlaces get the result inline. > > As lo

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Dave
On 22 Feb 2013, at 13:57, Uli Kusterer wrote: performSelector doesn't take care of locking non-threadsafe data structures, avoiding deadlocks in aforementioned logs etc. Although e.g. Cocoa's UI classes have improved a lot WRT thread-safety in recent MacOS releases, it's still not safe to

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Uli Kusterer
performSelector doesn't take care of locking non-threadsafe data structures, avoiding deadlocks in aforementioned logs etc. Although e.g. Cocoa's UI classes have improved a lot WRT thread-safety in recent MacOS releases, it's still not safe to drive arbitrary controls from another thread. Simila

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Dave
Hi, Hi, On 22 Feb 2013, at 11:29, Uli Kusterer wrote: in short: Network processes can take a long time (high traffic, 14.4k modems, ...). If you are using a synchronous call on the main thread, your application will be completely blocked from doing anything else. The CPU will sit ther

Re: [OT] Sync vs ASync Server Comms

2013-02-22 Thread Uli Kusterer
Hi, in short: Network processes can take a long time (high traffic, 14.4k modems, ...). If you are using a synchronous call on the main thread, your application will be completely blocked from doing anything else. The CPU will sit there idle, not doing anything until the transfer has finished.

[OT] Sync vs ASync Server Comms

2013-02-22 Thread Dave
Hi All, I was reading an article about Server/Client communications using a Rest service and the author seemed to have a downer on using the Sync (as opposed to ASync) methods of making a request and receiving a reply. Also I've noticed it being generally discouraged in quite a few other