[SYN]

This is perhaps the biggest flaw Carbon has, and probably why most people feel it is inferior to Cocoa. holding a mouse clic in IE will render the browser useless, ala OS9. So is this fixed in Jaguar? Or is this under NDA too???

[kamprath]

Originally posted by SYN:
<STRONG>This is perhaps the biggest flaw Carbon has, and probably why most people feel it is inferior to Cocoa. holding a mouse clic in IE will render the browser useless, ala OS9. So is this fixed in Jaguar? Or is this under NDA too???</STRONG>

I would attribute this more to a IE flaw than a carbon flaw. Proper use of carbon events would not yield these results. With that said, there are some controls in Carbon which themselves don;t use Carbon Events for tracking mouse clicks.

[Big Mac]

Kamprath is right on. Proper use of the Carbon Events model allows Carbon apps to act properly. Even though it's not the best example due to inefficiency, take a look at the Carbon based iTunes. It doesn't stop its counter while menus are held down.

[Smircle]

Originally posted by SYN:

This is perhaps the biggest flaw Carbon has, and probably why most people feel it is inferior to Cocoa. holding a mouse clic in IE will render the browser useless, ala OS9. So is this fixed in Jaguar? Or is this under NDA too???

Judging from what I know about the 10.1 Toolbox, Jaguars Carbon implementation is not going to be fully reentrant (Parts of the filemanager and Open Transport have been reentrant for very long times). However I think you are mixing stuff here. You can achieve concurrent operation of various UI parts even with the current model using threading and Carbon Events.

FWIW the Cocoa UI classes are not fully reentrant either.

[iJed]

Do Apple intend to make Carbon and Cocoa fully reentrant? I once read that it was their intention to make Carbon reentrant for Mac OS X 10.1... That never seemed to happen but I would assume that they are still working on it?

[kamprath]

Originally posted by iJed:
<STRONG>Do Apple intend to make Carbon and Cocoa fully reentrant? I once read that it was their intention to make Carbon reentrant for Mac OS X 10.1... That never seemed to happen but I would assume that they are still working on it?</STRONG>

Blind adhearance to buzz-words is not what is really wanted. Carbon is re-entrant where it makes sense - in the UI event model.

[SoClose]

Originally posted by iJed:
<STRONG>Do Apple intend to make Carbon and Cocoa fully reentrant? I once read that it was their intention to make Carbon reentrant for Mac OS X 10.1... That never seemed to happen but I would assume that they are still working on it?</STRONG>

I would say that it's safe to assume that Apple has lots of discussion around making the UI portions of the Carbon Toolbox re-entrant. One problem is how to balance the defensive coding posture necessary for supporting reentrancy at this level with the possible performance hit. Plus, it would probably require some significant API changes. In order for Apple to update OpenTransport, they had to change the API set to take a context parameter to allow the code to keep track of who called it. Reentrancy makes a lot of sense at the network level, but I'm not convinced of the benefits at the UI API level -- I believe that even the mighty Windows does not have a reentrant user interface API set.

[bewebste]

Originally posted by kamprath:
<STRONG>

Blind adhearance to buzz-words is not what is really wanted. Carbon is re-entrant where it makes sense - in the UI event model.</STRONG>

There are many many other places in Carbon that are not reentrant which make it a total pain to support multithreading. Some examples are the Apple event manager, the process manager, the resource manager... I could list many more. Right now, you can't count on squat to be MP safe and are severely limited as to what you can actually do in separate threads.

[kamprath]

Originally posted by bewebste:
<STRONG>

There are many many other places in Carbon that are not reentrant which make it a total pain to support multithreading. Some examples are the Apple event manager, the process manager, the resource manager... I could list many more. Right now, you can't count on squat to be MP safe and are severely limited as to what you can actually do in separate threads.</STRONG>

Ah, multi-threading would require more than just re-entrancy, but it is require. However, the guy's original complaint was how when holding down a click in IE, every other UI aspect comes to a halt. Multi-threading is not required to have you UI-experience to be "multi-tasked". Supporting the carbon event model (which does requires your callbacks to be re-entrant) is sufficient to provide the rich UI experience.

[clarkgoble]

I notice that most of the Carbon stuff you mentioned that isn't re-entrant is also stuff that is being phased out in OSX.

[SYN]

this is not about buzz-word compliance. This is about my file copies in the Finder stopping if I move a window, this is Stuffit stopping completely when I move the window since it doesn't seem to release clics so it thinks I'm stil clicking it, until I click again. Is this only related to threading? Why doesn't Apple use it's own Carbon Events in it's apps, especially the finder?

Windows doesn't have re-entrancy, but BeOS did. And OSX should too, an operation stopping simply because you're moving a window is ridiculous. Perhaps acceptable in badly coded apps, but Apple should at least code it's own apps properly.

[kamprath]

Originally posted by SYN:
<STRONG>this is not about buzz-word compliance. This is about my file copies in the Finder stopping if I move a window, this is Stuffit stopping completely when I move the window since it doesn't seem to release clics so it thinks I'm stil clicking it, until I click again. Is this only related to threading? Why doesn't Apple use it's own Carbon Events in it's apps, especially the finder?

Windows doesn't have re-entrancy, but BeOS did. And OSX should too, an operation stopping simply because you're moving a window is ridiculous. Perhaps acceptable in badly coded apps, but Apple should at least code it's own apps properly.</STRONG>

Your statement indicates you don't really care about "re-entrancy", but about "UI multi-tasking." This is a difference between the two. Be careful what you ask for, because you might not get what you really want. Trying to request your requirements by specifying seemingly related low-level technical details is a recipe for not getting what you really want. The low-level technical detail that is really related to what you want is the use of Carbon Events. So you see, if you got your way with re-entrancy, it does no good for your desire to have a multi-tasking UI because that doesn't mean Carbon Events are being used.

Sorry about splitting hairs, but I do requirements generation for a living. By requesting low-level technical requirements in order to accomplish a more general goal, you are falling vistim to the "buzzword compliance" trap. "Buzzword compliance" should never be a requirement - unless of course you are in marketing.

[SYN]

Your statement indicates you don't really care about "re-entrancy", but about "UI multi-tasking." This is a difference between the two. Be careful what you ask for, because you might not get what you really want. Trying to request your requirements by specifying seemingly related low-level technical details is a recipe for not getting what you really want. The low-level technical detail that is really related to what you want is the use of Carbon Events. So you see, if you got your way with re-entrancy, it does no good for your desire to have a multi-tasking UI because that doesn't mean Carbon Events are being used.

Sorry about splitting hairs, but I do requirements generation for a living. By requesting low-level technical requirements in order to accomplish a more general goal, you are falling vistim to the "buzzword compliance" trap. "Buzzword compliance" should never be a requirement - unless of course you are in marketing.

I apologise, I'm a very early *beginner* as far as development goes, sorry about that

So then is there a reason why the Finder and other Apple apps do not use Carbon Events? supposedly the Carbon has no legacy code, so why does it not support the new APIs?

[absmiths]

Originally posted by SYN:
<STRONG>
So then is there a reason why the Finder and other Apple apps do not use Carbon Events? supposedly the Carbon has no legacy code, so why does it not support the new APIs?</STRONG>

I may be completely wrong about this, but I believe that probably the majority of the Carbon codebase is legacy code. At the very least it is a legacy API by definition.

About the re-entrant UI thing, many UI toolkits are not reentrant - Java/Swing is a huge example. The app can be multithreaded but special code is required to access the UI widgets themselves. A single-threaded UI can actually be a really nice design so long as it has a proper API to support it.

As far as the Finder goes, probably not even Carbon Events would help it. The entire file copy operation needs to occur on a separate thread from the main Finder itself (meaning completely separate - if the copy thread is synchronized with the main Finder thread then you are effectively single-threaded). I am using the term 'thread' loosely here, probably a separate process is actually in order. At that point, whatever model is used to update the UI - either re-entrant or not, the user has a true 'multi-tasked' experience.

[ 05-21-2002: Message edited by: absmiths ]

[aleph_null]

Originally posted by absmiths:
<STRONG>
I may be completely wrong about this, but I believe that probably the majority of the Carbon codebase is legacy code. At the very least it is a legacy API by definition.
</STRONG>

this is perhaps true to an extent on OS9, but i'd wager that in OSX there's been a non-trivial amount of re-writing going on for the past several years. (and still going on, for that matter ...) for example, last i time i checkes, you could ignore the opacity of some toolbox types, such as windows, on OS9, treat WindowRefs as WindowPtrs and such, and not crash horribly. not true on OS X.

and Carbon as a whole should not be considered legacy, in my opinion. it's actually maturing quite nicely.

<STRONG>
About the re-entrant UI thing, many UI toolkits are not reentrant - Java/Swing is a huge example. The app can be multithreaded but special code is required to access the UI widgets themselves. A single-threaded UI can actually be a really nice design so long as it has a proper API to support it.
</STRONG>

yeah ... i can understand wanting to touch UI from elsewhere than the main thread, but really it's not a bad idea to keep all drawing in one thread, anyway. it's dead easy to communicate between threads using Carbon Events or Carbon Timers. so when a worker thread wants some ui to change, it need only signal the main thread, which can wake up at a convenient time and do the ui work it needs. if you build it this way from the ground up, i'd say it's a cleaner design.

[iJed]

Originally posted by absmiths:
<STRONG>

I may be completely wrong about this, but I believe that probably the majority of the Carbon codebase is legacy code. At the very least it is a legacy API by definition.

[ 05-21-2002: Message edited by: absmiths ]</STRONG>

If I remember correctly then the original Mac API (and OS) were written in Pascal. I would assume that Apple has rewritten all Pascal parts for the Mac OS X implementation of Carbon. GCC does not currently have a Pascal FE as far as I know. However maybe nothing remained of the Pascal code by Mac OS 9.x.

[King Chung Huang]

Originally posted by iJed:
<STRONG>If I remember correctly then the original Mac API (and OS) were written in Pascal. I would assume that Apple has rewritten all Pascal parts for the Mac OS X implementation of Carbon. GCC does not currently have a Pascal FE as far as I know. However maybe nothing remained of the Pascal code by Mac OS 9.x.</STRONG>

I believe the transition from Pascal to C was completed during the System 7 era, though I'm not 100% sure.