IPC help.... I need help.. PLZZZZ it is very urgent!!!!! - Minix

This is a discussion on IPC help.... I need help.. PLZZZZ it is very urgent!!!!! - Minix ; MINIX currently supports several message passing IPC primitives that blocks the sender or receiver user processes if their counter part is not already waiting for the message. I need to develop new IPC primitives on MINIX (in addition to those ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!

  1. IPC help.... I need help.. PLZZZZ it is very urgent!!!!!

    MINIX currently supports several message passing IPC primitives
    that blocks the sender or receiver user processes if their counter
    part is not already waiting for the message. I need to develop new IPC
    primitives on MINIX (in addition to those that are available) that
    will allow the sender or receiver to also be unblocked by a timer
    specified in the application program.
    Some one help meee plzzzzzzzzzzzz..


  2. Re: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!


    ricky.sa.2000@gmail.com writes:

    > MINIX currently supports several message passing IPC primitives
    > that blocks the sender or receiver user processes if their counter
    > part is not already waiting for the message. I need to develop new IPC
    > primitives on MINIX (in addition to those that are available) that
    > will allow the sender or receiver to also be unblocked by a timer
    > specified in the application program.


    > Some one help meee plzzzzzzzzzzzz..

    ^^^^^^^^^^^^^^^^

    Remember people: Always pull the power plug before opening the casing.

    Regards -- Markus


  3. Re: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!

    On Mar 30, 3:12 am, Markus E Leypold
    wrote:
    > ricky.sa.2...@gmail.com writes:
    > > MINIX currently supports several message passing IPC primitives
    > > that blocks the sender or receiver user processes if their counter
    > > part is not already waiting for the message. I need to develop new IPC
    > > primitives on MINIX (in addition to those that are available) that
    > > will allow the sender or receiver to also be unblocked by a timer
    > > specified in the application program.
    > > Some one help meee plzzzzzzzzzzzz..

    >
    > ^^^^^^^^^^^^^^^^
    >
    > Remember people: Always pull the power plug before opening the casing.
    >
    > Regards -- Markus


    Man,... I'm serious here.. It's a matter of life and death!!!! so,
    plzz help!!!


  4. Re: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!


    ricky.sa.2000@gmail.com writes:

    > On Mar 30, 3:12 am, Markus E Leypold
    > wrote:
    >> ricky.sa.2...@gmail.com writes:
    >> > MINIX currently supports several message passing IPC primitives
    >> > that blocks the sender or receiver user processes if their counter
    >> > part is not already waiting for the message. I need to develop new IPC
    >> > primitives on MINIX (in addition to those that are available) that
    >> > will allow the sender or receiver to also be unblocked by a timer
    >> > specified in the application program.
    >> > Some one help meee plzzzzzzzzzzzz..

    >>
    >> ^^^^^^^^^^^^^^^^
    >>
    >> Remember people: Always pull the power plug before opening the casing.
    >>
    >> Regards -- Markus

    >
    > Man,... I'm serious here.. It's a matter of life and death!!!!


    So am I: Not disconnecting the power before opening an electrical
    appliance might well be a matter of death :-).

    Concerning your specific request: Maybe it is easy to provide the
    functions you're looking for by some ingenious hackery. But from the
    distance I cannot see a way. I seems quite a piece of developement to
    me ... -- my suggestion would be NOT to add new PRIMITIVES (after all,
    they are called primitives because they are minimal and orthogonal to
    a certain extent) but develop a separate IPC server for your
    purposes.

    (Concerning the alternative to extend the process tables with time
    intervalls and collect timed out processes regularly: I've the
    impression this will end up in a mess, but I cannot say for sure: I'd
    have to have a better look at the relevant parts of the kernel and the
    MM).

    You would perhaps also need a timer server (or can we get that effect
    from already existing code -- the alarm(2) syscall must be implemented
    somehow. Which gives me a new idea: Is sendrec() interrupted by a
    signal? Probably, considering, that read() and write() which ARE
    interrupted must be implemented on top of sendrec. So another (the
    third option) would be to use alarm(2) and SIGALRM to timeout the
    sendrec(). But this would be purely library level, hardly a primitive
    an would come at the price of SIGALRM/alarm(2) being only partially
    usable for other purposes any more: Hardly a "primitive" in my eyes.

    Well -- Presently I fail to see why that all should be a matter of
    life and death. If it really is, you might consider to outsource this
    problem to some paid consultant as contract work :-). E.g. to me.

    If it is only homework that would probably be overkill, but then I
    cannot imagine it being a matter of life and death also.

    Regards -- Markus


  5. Re: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!

    On Mar 30, 5:03 pm, Markus E Leypold
    wrote:
    > ricky.sa.2...@gmail.com writes:
    > > On Mar 30, 3:12 am, Markus E Leypold
    > > wrote:
    > >> ricky.sa.2...@gmail.com writes:
    > >> > MINIX currently supports several message passing IPC primitives
    > >> > that blocks the sender or receiver user processes if their counter
    > >> > part is not already waiting for the message. I need to develop new IPC
    > >> > primitives on MINIX (in addition to those that are available) that
    > >> > will allow the sender or receiver to also be unblocked by a timer
    > >> > specified in the application program.
    > >> > Some one help meee plzzzzzzzzzzzz..

    >
    > >> ^^^^^^^^^^^^^^^^

    >
    > >> Remember people: Always pull the power plug before opening the casing.

    >
    > >> Regards -- Markus

    >
    > > Man,... I'm serious here.. It's a matter of life and death!!!!

    >
    > So am I: Not disconnecting the power before opening an electrical
    > appliance might well be a matter of death :-).
    >
    > Concerning your specific request: Maybe it is easy to provide the
    > functions you're looking for by some ingenious hackery. But from the
    > distance I cannot see a way. I seems quite a piece of developement to
    > me ... -- my suggestion would be NOT to add new PRIMITIVES (after all,
    > they are called primitives because they are minimal and orthogonal to
    > a certain extent) but develop a separate IPC server for your
    > purposes.
    >
    > (Concerning the alternative to extend the process tables with time
    > intervalls and collect timed out processes regularly: I've the
    > impression this will end up in a mess, but I cannot say for sure: I'd
    > have to have a better look at the relevant parts of the kernel and the
    > MM).
    >
    > You would perhaps also need a timer server (or can we get that effect
    > from already existing code -- the alarm(2) syscall must be implemented
    > somehow. Which gives me a new idea: Is sendrec() interrupted by a
    > signal? Probably, considering, that read() and write() which ARE
    > interrupted must be implemented on top of sendrec. So another (the
    > third option) would be to use alarm(2) and SIGALRM to timeout the
    > sendrec(). But this would be purely library level, hardly a primitive
    > an would come at the price of SIGALRM/alarm(2) being only partially
    > usable for other purposes any more: Hardly a "primitive" in my eyes.
    >
    > Well -- Presently I fail to see why that all should be a matter of
    > life and death. If it really is, you might consider to outsource this
    > problem to some paid consultant as contract work :-). E.g. to me.
    >
    > If it is only homework that would probably be overkill, but then I
    > cannot imagine it being a matter of life and death also.
    >
    > Regards -- Markus- Hide quoted text -
    >
    > - Show quoted text -


    Could you tell me more on this? Like, what all code has to be
    modified?


  6. Re: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!


    ricky.sa.2000@gmail.com writes:

    > On Mar 30, 5:03 pm, Markus E Leypold
    > wrote:
    >> ricky.sa.2...@gmail.com writes:
    >> > On Mar 30, 3:12 am, Markus E Leypold
    >> > wrote:
    >> >> ricky.sa.2...@gmail.com writes:
    >> >> > MINIX currently supports several message passing IPC primitives
    >> >> > that blocks the sender or receiver user processes if their counter
    >> >> > part is not already waiting for the message. I need to develop new IPC
    >> >> > primitives on MINIX (in addition to those that are available) that
    >> >> > will allow the sender or receiver to also be unblocked by a timer
    >> >> > specified in the application program.
    >> >> > Some one help meee plzzzzzzzzzzzz..

    >>
    >> >> ^^^^^^^^^^^^^^^^

    >>
    >> >> Remember people: Always pull the power plug before opening the casing.

    >>
    >> >> Regards -- Markus

    >>
    >> > Man,... I'm serious here.. It's a matter of life and death!!!!

    >>
    >> So am I: Not disconnecting the power before opening an electrical
    >> appliance might well be a matter of death :-).
    >>
    >> Concerning your specific request: Maybe it is easy to provide the
    >> functions you're looking for by some ingenious hackery. But from the
    >> distance I cannot see a way. I seems quite a piece of developement to
    >> me ... -- my suggestion would be NOT to add new PRIMITIVES (after all,
    >> they are called primitives because they are minimal and orthogonal to
    >> a certain extent) but develop a separate IPC server for your
    >> purposes.
    >>
    >> (Concerning the alternative to extend the process tables with time
    >> intervalls and collect timed out processes regularly: I've the
    >> impression this will end up in a mess, but I cannot say for sure: I'd
    >> have to have a better look at the relevant parts of the kernel and the
    >> MM).
    >>
    >> You would perhaps also need a timer server (or can we get that effect
    >> from already existing code -- the alarm(2) syscall must be implemented
    >> somehow. Which gives me a new idea: Is sendrec() interrupted by a
    >> signal? Probably, considering, that read() and write() which ARE
    >> interrupted must be implemented on top of sendrec. So another (the
    >> third option) would be to use alarm(2) and SIGALRM to timeout the
    >> sendrec(). But this would be purely library level, hardly a primitive
    >> an would come at the price of SIGALRM/alarm(2) being only partially
    >> usable for other purposes any more: Hardly a "primitive" in my eyes.
    >>
    >> Well -- Presently I fail to see why that all should be a matter of
    >> life and death. If it really is, you might consider to outsource this
    >> problem to some paid consultant as contract work :-). E.g. to me.
    >>
    >> If it is only homework that would probably be overkill, but then I
    >> cannot imagine it being a matter of life and death also.
    >>
    >> Regards -- Markus-


    > Could you tell me more on this? Like, what all code has to be
    > modified?


    No. Or better, not yet.

    Let me explain: In my eyes there are 2 possibilities:

    (a) This is actually homework: Then it's not a matter of life and
    death, you've been bull****ting us and my/our time is wasted.I'd
    probably point you into the right direction if you talked
    candidly to us.

    (b) This is part of a product/solution development: Then I'm not
    working for free for you. Furthermore your posting seems to
    indicate that you still need someone with the necessary expertise
    to advise your team. Ask for my proposition. :-)

    Personally I tend to think (a) -- but I'm ready for (b). :-)

    Note that I don't just refuse to disclose information to you that
    would be readily available for me. Quite the opposite: I sketched 3
    approaches (and you have not specified which would satisfy your "new
    primitives" requirement), all of which need further research before
    providing an implementation plan.

    Now what is it: (a) or (b)?

    Regards -- Markus

  7. Re: IPC help.... I need help.. PLZZZZ it is very urgent!!!!!


    Hm. No answer to my last post from "ricky". Perhaps he's already dead,
    chocked on a blocked message. Those matters of live and death always
    get to me ...

    :-)

    Regards -- Markus

+ Reply to Thread