Re: Need help in Mac Networking.
Re: Need help in Mac Networking.
- Subject: Re: Need help in Mac Networking.
- From: Zack Morris <email@hidden>
- Date: Sat, 2 Oct 2004 15:03:39 -0600
On Oct 2, 2004, at 2:17 PM, Kent Sorensen wrote:
You should not use the PowerPlant networking classes on OS X.
Especially on multiprocessor machines you will experience random
crashes. That problem is well documented.
OpenTransport is dead. It exists on OS X only as a compatibility layer
on top of the BSD sockets, This compatibility is good but not perfect
and that is the reason for the instability of the PowerPlant classes.
Network programming on OS X either means plain socket programming as
it is after all a UNIX system, or if you prefer a slightly higher
abstraction you can use CFNetwork and similar API.
CFNetwork etc. has miserable documentation but socket programming is
very well known. Stevens UNIX network programming book is the bible.
Kent Sorensen
http://www/snak.com
This might be a really dumb question but...is there a threading model
in unix that acts like an interrupt? The reason that most notifier
driven OpenTransport apps die on X is that the notifier can be stalled
to allow the main thread to execute. On 9, the notifier always ran to
completion before execution was given back to the main thread. There
needs to be a way to prioritize threads in unix so that one thread
can't be suspended for a thread of lower priority, which would emulate
interrupts exactly. If unix/the kernel can't be told to do this, I
think that this is a huge hole, and I'd like to see Darwin add that
ability, even if it breaks other unixes (they should have had that
ability anyway). This would also be very useful for scientific apps,
and even for music or graphics double buffering, actually I can think
of dozens of places where being able to give threads priority would
make life better. Just to get one thing clear, this prioritization
should only occur for the threads in an app, not for the rest of the
OS.
P.S. Off the top of my head, I can see where this is hard to think
about, because threads run forever, whereas interrupts are fired and
then end. OT on X could just as easily spawn a thread and not let the
main thread resume until the interrupt thread has ended. Overhead is
not so much an issue here, it's far more important that an app doesn't
crash. Another idea is to only suspend the interrupt thread when it
explicitly calls usleep() for instance, but never due to a timeout.
Then have OT call usleep() internally, outside of the notifier, so that
the programmer doesn't need to know it is happening.
P.P.S. The fact that you can't simply port most notifier apps to X
without them crashing says to me that OT is not finished, and shouldn't
have been closed until they wrote a workaround (even if that involved
extending the threading model). I seem to remember something about
OTEnterNotifier() and OTLeaveNotifier() working as sort of a mutex from
the main thread on X, but it seemed like there were gotchas with that
method also.
------------------------------------------------------------------------
Zack Morris Z Sculpt Entertainment This Space
email@hidden http://www.zsculpt.com For Rent
------------------------------------------------------------------------
If the doors of perception were cleansed, everything would appear to man
as it is, infinite. -William Blake, The Marriage of Heaven and Hell
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden