• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Open Transport and MultiProcessing Services
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open Transport and MultiProcessing Services


  • Subject: Re: Open Transport and MultiProcessing Services
  • From: Quinn <email@hidden>
  • Date: Fri, 21 May 2004 11:42:03 +0100

At 23:25 +0400 19/5/04, Igor garnov wrote:
In reply to my mail a couple of months ago you wrote that Open Transport routines in OTMP sample utilize slightly different technique, which has something to do with deferred tasks, but not MPRemoteCall.

Yeah, I forgot that OTMP uses DTInstall rather than MPRemoteCall. However, it makes little difference between DTInstall and MPRemoteCall share the same fundamental technology that's used for low-latency MP-to-blue communications.

Now my question is - in your personal opinion, is it worth it to use the approach with deferred task rather than just use MPRemoteCall?

If your goal is a low-latency communications path between MP tasks and Open Transport running in the blue task, DTInstall is your friend. That's because, on the blue side, you're not allowed to call OT from true interrupt time; rather, you must call it from a deferred task. So, if you use MPRemoteCall, you end up having to schedule a deferred task on the blue side of things anyway. If you're going to do that, you might as well use DTInstall directly from MP.

I am asking this because having a look at OTMP I understand that it is rather complex and will take some time to understand.

OTMP is complex because it implements a synchronous blocking network API in terms of an asynchronous API. That itself is inherently complicated, and it's further complicated by the need to handle the MP-to-blue and blue-to-MP communications correctly and efficiently.

In your case you want to implement as asynchronous networking API on top of an asynchronous networking API, which makes things a little simpler. However, you still have to manage MP-to-blue and blue-to-MP communications. So, your code will end up having a lot in common with OTMP. I particularly recommend that you implement comprehensive logging (steal the OTMP or write your own): it will be very difficult for you to debug without this.

S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.


References: 
 >Re: Open Transport and MultiProcessing Services (From: Igor garnov <email@hidden>)

  • Prev by Date: Re: POSIX sockets and event loops
  • Next by Date: Re: gethostname
  • Previous by thread: Re: Open Transport and MultiProcessing Services
  • Next by thread: Soap Server.
  • Index(es):
    • Date
    • Thread