On Mar 14, 2012, at 2:09 PM, Wade Tregaskis wadesli...@mac.com wrote:
I don't like the idea of a multithreaded aproach by default, because as a
general rule, you
should not make your application multithreaded unless you have a good
reason.
b) This convenientional wisdom is, in my humble
At 1:40 PM -0700 3/14/12, JongAm Park wrote:
On 3/14/2012 10:27 AM, Scott Ribe wrote:
On Mar 14, 2012, at 11:23 AM, JongAm Park wrote:
it didn't sound harsh in a jungle with full of male creatures.
LOL! And you said your English was not so good. That was great!
Well, I was not born in
Den 22:09 14. mars 2012 skrev Wade Tregaskis wadesli...@mac.com følgende:
I don't like the idea of a multithreaded aproach by default, because as a
general rule, you
should not make your application multithreaded unless you have a good
reason.
a) The reality is that Cocoa already exposes
Den 12:03 15. mars 2012 skrev Per Bull Holmen pbhol...@gmail.com følgende:
I agree with what you are saying,
but remember that we MAY also move towards new concepts and
abstractions that make todays concept of multithreading an antiquated
way of achieving parallelism. For example,
While all these points are very good, I disagree with the conclusion
because I believe in the wisdom: Keep simple things simple.
An argument for doing this in the frameworks is that it is then simpler to do
this. No need for every developer to write the same boiler plate every time.
And if
Den 18:06 15. mars 2012 skrev Wade Tregaskis wadesli...@mac.com følgende:
Highly subjective, though, I recognise that. I think we've pretty much run
this discussion to its end now, and it doesn't appear I've swayed you.
That's okay.
Yes we have, but you have actually swayed me... :)
You
On Mar 13, 2012, at 3:09 PM, JongAm Park wrote:
In other words, the thread function may want to update UI like inserting a
log message to a text field on a window and thus asking main thread to do so,
and main thread is waiting to acquire a lock or waiting using Join, then
either the main
On Mar 14, 2012, at 9:21 AM, JongAm Park wrote:
Of course. So, it is better to avoid such case, just like threading itself.
That's really not what I meant. I meant that if you're at the level that you
design things such that the main thread and background worker threads deadlock,
adding more
Scott, it's not that any one thing is hard to get correct. Arrogantly
calling someone stupid, as you've done here, doesn't help. It's
the subtlety of getting *everything* correct. A GUI system, and the
programs that are layered on top of it, embody a great deal of complexity.
Allowing multiple
On Mar 14, 2012, at 10:07 AM, Brian Lambert wrote:
Scott, it's not that any one thing is hard to get correct. Arrogantly
calling someone stupid, as you've done here, doesn't help.
I didn't call anyone stupid--that's your inference, not mine.
I did point out that someone who thinks he can
Threads themselves are very useful; multiple threads taking user input and
updating the display to the user are not really useful, and the request for
them more often than not betrays a lack of understanding of threading.
So you think it'd be great it every GUI app shared the same serial
Ouch. If you think that's a problem, then trust me, you would really make
a mess with multiple UI threads.
That isn't calling someone stupid? Really?
Ah, OK. My inference processor must be in error.
On Wed, Mar 14, 2012 at 9:14 AM, Scott Ribe scott_r...@elevated-dev.comwrote:
On Mar 14,
On Mar 14, 2012, at 10:17 AM, Brian Lambert wrote:
Ouch. If you think that's a problem, then trust me, you would really make a
mess with multiple UI threads.
That isn't calling someone stupid? Really?
No, it's calling someone inexperienced with the domain and unprepared to deal
with a
On Mar 14, 2012, at 9:19 AM, Wade Tregaskis wrote:
Having a UI framework that either offloads some of this for you can actually
be very useful. It would also be closer to the user experience we're trying
to portray - for example, that each document on an app is totally
independent.
On Mar 14, 2012, at 12:07 PM, Brian Lambert wrote:
Scott, it's not that any one thing is hard to get correct. Arrogantly
calling someone stupid, as you've done here, doesn't help.
Sounds like you're putting words in Scott's mouth Brian.
On Wed, Mar 14, 2012 at 6:43 AM, Scott Ribe
Den 17:19 14. mars 2012 skrev Wade Tregaskis wadesli...@mac.com følgende:
The reality is of course more of a compromise. It's quite common to do
drawing across multiple threads, though you still synchronise the final
blits around a single thread (i.e. the main thread).
Isn't that still
On Mar 13, 2012, at 2:09 PM, JongAm Park jongamp...@sbcglobal.net wrote:
In other words, the thread function may want to update UI like inserting a
log message to a text field on a window and thus asking main thread to do so,
and main thread is waiting to acquire a lock or waiting using
Umm.. Mr Lambert..
It's OK. I'm not offended.
If I confess, I felt a little uncomfortable, because I understand pretty
well this kind of stuff but he put an emphasis by saying mess. But we
are talking in a text based media which doesn't convey facial expression
or tone of voice.
So, based on
Umm.. Mr Lambert..
It's OK. I'm not offended.
If I confess, I felt a little uncomfortable, because I understand pretty
well this kind of stuff but he put an emphasis by saying mess. But we
are talking in a text based media which doesn't convey facial expression
or tone of voice.
So, based on
On 3/14/2012 9:14 AM, Scott Ribe wrote:
On Mar 14, 2012, at 10:07 AM, Brian Lambert wrote:
Scott, it's not that any one thing is hard to get correct. Arrogantly calling
someone stupid, as you've done here, doesn't help.
I didn't call anyone stupid--that's your inference, not mine.
I did
On Mar 14, 2012, at 11:23 AM, JongAm Park wrote:
it didn't sound harsh in a jungle with full of male creatures.
LOL! And you said your English was not so good. That was great!
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
On Mar 14, 2012, at 11:05 AM, Gary L. Wade wrote:
To solve your thinking on this matter, conceptualize the background thread as
a (M)odel object, the main thread a (V)iew object, and possibly an
NSMutableArray of NSStrings each having an individual log message being a
(C)ontroller object.
Le 14 mars 2012 à 17:52, Per Bull Holmen a écrit :
Den 17:19 14. mars 2012 skrev Wade Tregaskis wadesli...@mac.com følgende:
The reality is of course more of a compromise. It's quite common to do
drawing across multiple threads, though you still synchronise the final
blits around a
Likewise even event handling is often effectively multi-threaded, because
you dispatch from the main thread to a variety of tasks, queues or worker
threads.
But then you are receiving the events on the main thread? What do you
mean? If you receive events on the main thread, and dispatch
On 3/14/2012 9:19 AM, Wade Tregaskis wrote:
Threads themselves are very useful; multiple threads taking user input and
updating the display to the user are not really useful, and the request for
them more often than not betrays a lack of understanding of threading.
So you think it'd be great
Well, Mr. Ribe.
I'm sorry but I'm not inexperience with this domain.
I'm not trying to solve this problem with more complicated model.
I was to find out any rationale, I may not think of, behind the new
model, and a well-established code pattern to solve it.
JongAm Park
On 3/14/2012 9:23
Den 20:00 14. mars 2012 skrev Wade Tregaskis wadesli...@mac.com følgende:
On the other hand, you could have an event handling framework which
dispatched events to any of multiple threads/queues/whatever for you. For
example, each window might have its own queue. This actually makes a lot
On Mar 14, 2012, at 2:08 PM, JongAm Park wrote:
Because, as you said, there can be some situation where it is a lot easier
and better to allow accessing GUI widgets from any threads,
The problem of course, is that in order to allow that, the framework itself has
to be locking things all over
Yes. I agree. That is one of the approach I'm thinking of when I handled
similar issue with QuickTime.
Thanks,
On 3/14/2012 10:05 AM, Gary L. Wade wrote:
On Mar 13, 2012, at 2:09 PM, JongAm Parkjongamp...@sbcglobal.net wrote:
In other words, the thread function may want to update UI like
Well, I'm sorry if I confused you.
BTW, common advice to avoid threading doesn't mean that threading
should not be used.
Just like salt, if it is used for right occasion, it is very good.
However, when there are another way not to use thread but just to use
threading because it can be used is
On 3/14/2012 10:27 AM, Scott Ribe wrote:
On Mar 14, 2012, at 11:23 AM, JongAm Park wrote:
it didn't sound harsh in a jungle with full of male creatures.
LOL! And you said your English was not so good. That was great!
Well, I was not born in English-speaking country. So, sometimes my
English
The problem of course, is that in order to allow that, the framework itself
has to be locking things all over the place, regardless of whether or not an
app is actually accessing any particular data from multiple threads, because
now the framework has to assume that might happen.
Yes and
I don't like the idea of a multithreaded aproach by default, because as a
general rule, you
should not make your application multithreaded unless you have a good
reason.
a) The reality is that Cocoa already exposes you to a lot of concurrency and
asynchronisity, and is only going to do much
Back in the olden days in Director (1995-2001), I actually built an xplat
pseudo threading engine in the Lingo language for Director and Shockwave for
this exact purpose.
There was no robust model for thread locking as I simply said to myself don't
do anything stupid and handle your callbacks
Hello,
While doing projects with Cocoa and Objective-C, I have always thought
that allowing UI update only on main thread was a weak point of
Cocoa/Objective-C.
Especially, when gracefully terminating threads which would be better
update some UI stuff and if main thread is required to wait
On Mar 13, 2012, at 2:09 PM, JongAm Park wrote:
Is there any reason to design threading and UI update model like this?
Yes. Parallel computing with shared state is extremely hard. So hard that I
don’t think it’s even well-understood yet, in particular how one can properly
test such a system.
On Tue, Mar 13, 2012 at 4:09 PM, JongAm Park jongamp...@sbcglobal.net wrote:
In other words, the thread function may want to update UI like inserting a
log message to a text field on a window and thus asking main thread to do
so, and main thread is waiting to acquire a lock or waiting using
The short answer is that:
1) Given our current languages and tools, parallel programming is hard.
2) For the moment, it is generally the case that one thread is enough to
keep a UI updated and responding to events, thus avoiding #1.
3) When one thread isn't enough to keep a UI updated and
Notwithstanding the good advice about parallel programming given earlier in
this thread, there are still possible problems. By way of illustration, a year
or two ago I submitted a bug report (#8338166) about a problem of this sort in
iOS. I will describe the problem here. (I am not looking
39 matches
Mail list logo
