Well, actually not quite true. Pthreads has that mechanism with the join
facility. I like pthreads (er.. did before I began to grok GCD), but personally
have no use for pthread-join, and definitely don’t recommend its use, but it
does exactly this - waits for another thread to exit before contin
Hi,
This code (or the basis of it) was actually given to me by a Cocoa developer
from this list.
> On 30 Jun 2015, at 15:19, Andreas Grosam wrote:
>
> This kind of approach doesn't make sense and introduces a lot of issues.
It does make sense for certain kinds of problems and in the context i
This kind of approach doesn't make sense and introduces a lot of issues. You
occupy a thread which just waits for a result of a task (and thus merely
blocks). You doesn't cancel the async task properly when a timeout occurs. And
additionally you introduce a potential data race.
You could avo
Hi,
I do something like this which works really well but NOT on the Main Thread, on
a background thread.
-(NSData*) performSyncRequest
{
dispatch_group_tmyDispatchGroup;
//**
//**Create and Enter a Dispatch Group
//**
myDispatchGroup = dispa
On Jun 29, 2015, at 13:50 , Gavin Eadie wrote:
>
> The main thread is not involved in the above, but the idea of an
> “asynchronous-that-waits” == “apparently synchronous” call is demonstrated.
Yes, but you achieved that by blocking a background thread. It works because
you don’t care that the
On Jun 29, 2015, at 2:50 PM, Gavin Eadie wrote:
>
> The main thread is not involved in the above, but the idea of an
> “asynchronous-that-waits” == “apparently synchronous” call is demonstrated.
That's simply not asynchronous.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.
> On Jun 29, 2015, at 1:50 PM, Gavin Eadie wrote:
>
> This is all true for a “really synchronous” call, but my suggestion is that
> an “apparently synchronous” call only appears to wait; using a semaphore can
> stop the return, while things keep working on other threads.
I don’t think that’s
Somewhere in this email a lightbulb gets turned on!
> On Jun 29, 2015, at 2:49 PM, Scott Ribe wrote:
>
> The problem is that the requirement is self-contradictory: "synchronous"
> means wait, and "without impacting performance" means don't wait. While the
> real requirement is probably more li
On Jun 29, 2015, at 12:22 PM, Gavin Eadie wrote:
>
> Q: “Can anyone suggest a trick that allows an apparently synchronous call on
> the main thread without impacting performance?”
The problem is that the requirement is self-contradictory: "synchronous" means
wait, and "without impacting perfor
> On Jun 29, 2015, at 1:19 PM, Scott Ribe wrote:
>
>> The problem with the callback to “after” is that “after” is just the
>> continuation of the program and possibly nothing to do with what happens in
>> “fakeSyncrony” ..
>
> Then why does it need to wait?
>
> This is really sounding like pr
> On Jun 29, 2015, at 10:13 AM, Gavin Eadie wrote:
>
> The problem with the callback to “after” is that “after” is just the
> continuation of the program and possibly nothing to do with what happens in
> “fakeSyncrony” ..
Yeah, I don’t think you have any alternative but to restructure your co
On Jun 29, 2015, at 10:13 , Gavin Eadie wrote:
>
> I suppose the first thing “fakeSyncrony” could do is grab the address of the
> next instruction and make it the address to call back to. This sounds a
> little like Jens’ “crazy runtime manipulation of the stack
The mechanism you describe alr
On Jun 29, 2015, at 11:13 AM, Gavin Eadie wrote:
>
> The problem with the callback to “after” is that “after” is just the
> continuation of the program and possibly nothing to do with what happens in
> “fakeSyncrony” ..
Then why does it need to wait?
This is really sounding like program behav
> On Jun 29, 2015, at 12:28 PM, Scott Ribe wrote:
>
>> […] we have a counterexample in the form of the Canon ED-SDK, which somehow
>> does accomplish this.
>
> I seriously doubt that. It's probably performing the work on a background
> thread,
> then using some callback to execute the "after"
Use a background task to do the real work then deliver the result on a
queue. mUseba synchronous call to fetch the result from the queue or return
an error result if the queue is empty.
--
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
A
> On Jun 29, 2015, at 9:14 AM, Gavin Eadie wrote:
>
> Can anyone, with more knowledge than we have, suggest a trick that allows an
> apparently synchronous call on the main thread without impacting performance?
Not without some nasty hacks that I wouldn’t recommend.
The simplest one is to run
On Jun 29, 2015, at 10:14 AM, Gavin Eadie wrote:
>
> While it seems clear to me and my friend that this in an inescapable fact of
> life, we have a counterexample in the form of the Canon ED-SDK, which somehow
> does accomplish this.
I seriously doubt that. It's probably performing the work on
It’s standard knowledge that any operation which causes an app’s main thread to
wait is bad, and that diverting such delays off the main thread allows the app
to remain optimally responsive to external events. That diversion can happen
via a couple of mechanisms: ‘callbacks’ (delegation and cl
18 matches
Mail list logo
