Re: Ensuring stability of third party code in critical C system

Discussion in 'C Programming' started by Nobody, May 23, 2010.

  1. Nobody

    Nobody Guest

    On Sun, 23 May 2010 05:35:26 +0100, Nizumzen wrote:

    > Exposing a seperate API that wraps critical C library functions is the
    > method that I am leaning towards at the moment, but it is very likely
    > that I have missed something in my thinking. Can anyone help me out
    > with this at all? Is there anything that I have failed to consider?


    Wrapping functions won't help if the code corrupts memory (its own or
    yours).

    > The reason I am not overkeen on the sandbox idea is the huge added
    > complexity and system overhead associated with that.


    There doesn't have to be a great deal of overhead if you can communicate
    via shared memory and batch operations so that you don't have a context
    switch for every call. The feasibility of this approach depends greatly
    upon the nature of the task, though.

    Often, the biggest overhead comes from being unable to blindly trust the
    output, meaning that you have to sanity-check the data before you can
    use it.
    Nobody, May 23, 2010
    #1
    1. Advertising

  2. Nobody

    Tim Harig Guest

    On 2010-05-23, Nizumzen <> wrote:
    > On 2010-05-23 09:32:39 +0100, Nobody said:
    >> On Sun, 23 May 2010 05:35:26 +0100, Nizumzen wrote:
    >>> The reason I am not overkeen on the sandbox idea is the huge added
    >>> complexity and system overhead associated with that.

    >>
    >> There doesn't have to be a great deal of overhead if you can communicate
    >> via shared memory and batch operations so that you don't have a context
    >> switch for every call. The feasibility of this approach depends greatly
    >> upon the nature of the task, though.
    >>
    >> Often, the biggest overhead comes from being unable to blindly trust the
    >> output, meaning that you have to sanity-check the data before you can
    >> use it.

    >
    > True, but you would still need to have some mechanism in place for
    > private memory. It would be undesirable for all memory for the module
    > to be shared memory.


    What Nobody is referring to is sharing a segment between the two processes
    as an IPC mechanism. Only the segment that has been requested is shared
    and you have to explicity write information to that segment. Otherwise,
    the main memory (code, data, stack and heap segments, etc) is completely
    private between processes. Nobody mentions using shared memory because it
    is generally much faster then most other forms of IPC since it does not
    require assistance from the kernel.
    Tim Harig, May 23, 2010
    #2
    1. Advertising

  3. Nobody

    Nizumzen Guest

    On 2010-05-23 15:32:08 +0100, Tim Harig said:

    > On 2010-05-23, Nizumzen <> wrote:
    >> On 2010-05-23 09:32:39 +0100, Nobody said:
    >>> On Sun, 23 May 2010 05:35:26 +0100, Nizumzen wrote:
    >>>> The reason I am not overkeen on the sandbox idea is the huge added
    >>>> complexity and system overhead associated with that.
    >>>
    >>> There doesn't have to be a great deal of overhead if you can communicate
    >>> via shared memory and batch operations so that you don't have a context
    >>> switch for every call. The feasibility of this approach depends greatly
    >>> upon the nature of the task, though.
    >>>
    >>> Often, the biggest overhead comes from being unable to blindly trust the
    >>> output, meaning that you have to sanity-check the data before you can
    >>> use it.

    >>
    >> True, but you would still need to have some mechanism in place for
    >> private memory. It would be undesirable for all memory for the module
    >> to be shared memory.

    >
    > What Nobody is referring to is sharing a segment between the two processes
    > as an IPC mechanism. Only the segment that has been requested is shared
    > and you have to explicity write information to that segment. Otherwise,
    > the main memory (code, data, stack and heap segments, etc) is completely
    > private between processes. Nobody mentions using shared memory because it
    > is generally much faster then most other forms of IPC since it does not
    > require assistance from the kernel.


    Ah I see. Sorry, my mistake.
    Nizumzen, May 24, 2010
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kieran Benton
    Replies:
    3
    Views:
    503
    Ray Cassick \(home\)
    Sep 11, 2003
  2. Billy Porter
    Replies:
    0
    Views:
    1,015
    Billy Porter
    Jun 25, 2003
  3. crash.test.dummy
    Replies:
    0
    Views:
    336
    crash.test.dummy
    Mar 15, 2006
  4. sam
    Replies:
    3
    Views:
    388
    Abecedarian
    May 8, 2005
  5. aeromarine
    Replies:
    15
    Views:
    1,481
    Martin
    Feb 18, 2008
Loading...

Share This Page