Hello everyone,
I would like to start a thread (ha!) on multi-threaded programming on the 68000, in particular, how it might relate to MacTCP programming.
When I began developing MiniVNC, I did a bit of research and learned that there were two predominant ways to write MacTCP applications.
The first style appears to have been introduced by Steve Falkenburg in his article "MacTCP Cookbook: Constructing Network-Aware Applications." He provides synchronous high-level routines that make asynchronous calls to MacTCP functions and then does a busy loop to wait for the operation to complete. MacHTTP seems to be a historic app developed entirely using Steve Falkenburg's methods.
The second style is using asynchronous callback routines, which I learned about in the article "Asynchronous Routines on the Macintosh" in Develop magazine, March 1993. This is very efficient, as it eliminates busy-waiting, but it is much harder to do as it relies on callback routines that are called at interrupt time. Callback-based programming makes very simple things—like keeping state, branching, and looping—very hard. The fact that the callbacks are executed at interrupt time makes it even harder, as most Mac toolbox routines cannot safely be called from an interrupt. In practice, this means you need some mechanism for your callback routines to notify the main application loop to do certain operations, which adds to the complexity.
When I started developing MiniVNC, I knew that threads were a modern-day solution to this problem. I came across something very promising, Ari Halberstadt's ThreadLib, but at the time decided that learning to use both MacTCP and a potentially incompatible threading library would be too much of a heavy lift. So I developed MiniVNC entirely using asynchronous callbacks, which turned out to be just as much of a PITA as I had imagined it would be.
But now that I have been developing MiniVNC for two years, and pretty much know all the ins and outs of MacTCP, I want to revisit the question of whether multi-threading could be a good solution for MacTCP apps. What I wished I had was a library for network programming that would allow for a synchronous programming style like Steve Falkenburg's, but that instead of busy-waiting for MacTCP would suspend a thread until data was available. In addition, a thread could specify whether it wanted to be executed from the interrupt or from the main loop, so the developer would not need to implement message passing and other workarounds to accessing toolbox routines. I suspect Ari Halberstadt's work is a great starting point for this, but it would need additional work.
So, before I dig into this, I have a few questions for the community. Does anyone:
I would like to start a thread (ha!) on multi-threaded programming on the 68000, in particular, how it might relate to MacTCP programming.
When I began developing MiniVNC, I did a bit of research and learned that there were two predominant ways to write MacTCP applications.
The first style appears to have been introduced by Steve Falkenburg in his article "MacTCP Cookbook: Constructing Network-Aware Applications." He provides synchronous high-level routines that make asynchronous calls to MacTCP functions and then does a busy loop to wait for the operation to complete. MacHTTP seems to be a historic app developed entirely using Steve Falkenburg's methods.
The second style is using asynchronous callback routines, which I learned about in the article "Asynchronous Routines on the Macintosh" in Develop magazine, March 1993. This is very efficient, as it eliminates busy-waiting, but it is much harder to do as it relies on callback routines that are called at interrupt time. Callback-based programming makes very simple things—like keeping state, branching, and looping—very hard. The fact that the callbacks are executed at interrupt time makes it even harder, as most Mac toolbox routines cannot safely be called from an interrupt. In practice, this means you need some mechanism for your callback routines to notify the main application loop to do certain operations, which adds to the complexity.
When I started developing MiniVNC, I knew that threads were a modern-day solution to this problem. I came across something very promising, Ari Halberstadt's ThreadLib, but at the time decided that learning to use both MacTCP and a potentially incompatible threading library would be too much of a heavy lift. So I developed MiniVNC entirely using asynchronous callbacks, which turned out to be just as much of a PITA as I had imagined it would be.
But now that I have been developing MiniVNC for two years, and pretty much know all the ins and outs of MacTCP, I want to revisit the question of whether multi-threading could be a good solution for MacTCP apps. What I wished I had was a library for network programming that would allow for a synchronous programming style like Steve Falkenburg's, but that instead of busy-waiting for MacTCP would suspend a thread until data was available. In addition, a thread could specify whether it wanted to be executed from the interrupt or from the main loop, so the developer would not need to implement message passing and other workarounds to accessing toolbox routines. I suspect Ari Halberstadt's work is a great starting point for this, but it would need additional work.
So, before I dig into this, I have a few questions for the community. Does anyone:
- Know of any similar projects that might already do this?
- Have experience with Ari Halberstadt's library?
- Know what is the last version? I've only been able to locate ThreadLib 1.0d4
- Know of any real-world apps that already use it?
- Does anyone know of incompatibilities between it and Mac OS?
