[gmpi] Re: Reqs 5, 6, 11 for debate

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 21 Nov 2003 12:42:07 -0500

>>>>
>Under Linux (and presumably OSX) you can just say "all future momory I
>allocate from here should be page locked by default". Thus is becomes the
>hosts responsibility, and the plugin doesnt have to care.
><<<
>
>That's great for Linux, but today no such API exists in the Windows OS.  So
>if I write a GMPI plugin today for Windows XP, I'll have to change it to run
>on Longhorn, and then after my changes this plugin will break under XP
>unless I do a platform check to see if the API that I need is available.
>One goal of this is to not have to do platform checks in the plugin.

did you read steve's final point? 

microsoft's design for this is just *wrong*. it isn't going to work
without imposing severe language-level restrictions on code that runs
in "RT" context. you cannot make this work by specifying specific
sections of memory that should be locked because heap-based allocation
doesn't cover all the memory that is accessed.

>On the other hand, if we make the host responsible for a minimal set of
>platform services, this problem goes away.

it doesn't go away ron. it won't go away unless you can ensure that
all code, stack and data sections represented in the DLL are mapped to
locked down RAM, which means that the host now needs to use an
additional API to do that. in addition, as steve noted, languages like
C++ will do an end-run around the "host provided API" and will
allocate memory using call trees that likely terminate in a regular
malloc. all that has to happen is a single touch to such a page from
the DSP code and you fault. note that the allocation didn't have to
occur from within the DSP thread - the memory could have been setup by
a call to "new float[N]" in a regular thread.

is it clearer yet why MS' design is wrong, and why its worth paying
attention to a standard that has been doing this for more than 10
years? 

--p


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 11-2003