[Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs

Donovan Preston dp@ulaluma.com
Thu, 20 Dec 2001 12:34:05 -0800


--Apple-Mail-1-508474735
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Wednesday, December 19, 2001, at 02:32 PM, Jeff Harmon wrote:

Here is a summary of what I've encountered.  The machine in question is a
dual500 (g4) (with gobs o' RAM and perty much all the fix'ns).  It's 
running
a fully current (as of yesterday) 10.1.1 that started from an "consumer
boxed" 10.  I work for Adobe, btw.  I'm sure you've seen a lot of traffic
from some of us later since were thinking of adopting Python for some
internal use.  The jury is still out...

I've held off on contributing to this discussion, but I'm going to try 
to shed some more light into the dark corners of MacPython and hopefully 
help you out.

On OS 9 and before, the mac os had no built-in facility for handling 
stdio and therefore replacement libraries needed to be written to gain 
this functionality. The library in question is GUSI, the Grand Unified 
Socket Interface, which replaced much of the socket-based I/O behavior 
needed to port stdio-using apps to the Mac.

Unfortunately, GUSI was programmed with some assumptions about the 
innards of the OS taken for granted. One of those assumptions was that 
once an I/O completion callback was called at interrupt time, it would 
not be interrupted until the routine had finished. On OS X, however, 
this assumption no longer holds true. Any time an I/O completion 
callback is called (which tries to set a flag to let the main macpython 
thread know that some IO happened), MacPython enters a race condition 
hoping that function doesn't get preempted until it finishes.

On single processor machines, it's not as much of an issue (it seems to 
have been exaggerated by 10.1, however) but on dual processor machines, 
it seems the exceptional condition is almost always reached.

So what can be done about it?

OS X already has an implementation of socket-based IO -- it's called 
BSD. :-) And OS X already has a Python which will compile to use it -- 
command line Python. What OS X Python is missing, therefore, is the IDE 
running on top of the command-line Python binary. Stay tuned, hopefully 
we'll have it soon. See my message about Mach-O MacPython IDE if you're 
interested in knowing more.

first files, etc.)?  An alternative thought I have to work on is "how 
hard
will it be to glue the OS X CL interpreter (not MacPython) to PEF a 
gaggle
of libs?"  It looks doable but I've never traveled this road before.

That will definitely be the route you will be taking. There should be 
docs and sample code on Apple's dev web site about how to call a CFM 
(PEF) library from a Mach-O binary. It's possible. I unfortunately can't 
tell you exactly how to do it.

Good luck. If you decide to try to execute code stored in a CFM library 
from Mach-O Python, I'd be interested. This will probably be something I 
will need to do in order to use CFM VST plugins in the Mach-O based app 
I am writing.

Donovan


--Apple-Mail-1-508474735
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

On Wednesday, December 19, 2001, at 02:32 PM, Jeff Harmon wrote:

<color><param>0000,0000,DEDE</param>

Here is a summary of what I've encountered.  The machine in question
is a

dual500 (g4) (with gobs o' RAM and perty much all the fix'ns).  It's
running

a fully current (as of yesterday) 10.1.1 that started from an "consumer

boxed" 10.  I work for Adobe, btw.  I'm sure you've seen a lot of
traffic

from some of us later since were thinking of adopting Python for some

internal use.  The jury is still out...

</color>

I've held off on contributing to this discussion, but I'm going to try
to shed some more light into the dark corners of MacPython and
hopefully help you out.


On OS 9 and before, the mac os had no built-in facility for handling
stdio and therefore replacement libraries needed to be written to gain
this functionality. The library in question is GUSI, the Grand Unified
Socket Interface, which replaced much of the socket-based I/O behavior
needed to port stdio-using apps to the Mac.


Unfortunately, GUSI was programmed with some assumptions about the
innards of the OS taken for granted. One of those assumptions was that
once an I/O completion callback was called at interrupt time, it would
not be interrupted until the routine had finished. On OS X, however,
this assumption no longer holds true. Any time an I/O completion
callback is called (which tries to set a flag to let the main
macpython thread know that some IO happened), MacPython enters a race
condition hoping that function doesn't get preempted until it finishes.


On single processor machines, it's not as much of an issue (it seems
to have been exaggerated by 10.1, however) but on dual processor
machines, it seems the exceptional condition is almost always reached.


So what can be done about it?


OS X already has an implementation of socket-based IO -- it's called
BSD. :-) And OS X already has a Python which will compile to use it --
command line Python. What OS X Python is missing, therefore, is the
IDE running on top of the command-line Python binary. Stay tuned,
hopefully we'll have it soon. See my message about Mach-O MacPython
IDE if you're interested in knowing more.


<color><param>0000,0000,DEDE</param>first files, etc.)?  An
alternative thought I have to work on is "how hard

will it be to glue the OS X CL interpreter (not MacPython) to PEF a
gaggle

of libs?"  It looks doable but I've never traveled this road before.

</color>

That will definitely be the route you will be taking. There should be
docs and sample code on Apple's dev web site about how to call a CFM
(PEF) library from a Mach-O binary. It's possible. I unfortunately
can't tell you exactly how to do it.


Good luck. If you decide to try to execute code stored in a CFM
library from Mach-O Python, I'd be interested. This will probably be
something I will need to do in order to use CFM VST plugins in the
Mach-O based app I am writing.


Donovan



--Apple-Mail-1-508474735--