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
17 matches
Mail list logo
