Alarms - Minix

This is a discussion on Alarms - Minix ; The 'alarm' function allows a time period in seconds. Is there a library call that allows millisecond resolution alarms? Chris. -- http://www.minixtips.com...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Alarms

  1. Alarms

    The 'alarm' function allows a time period in seconds. Is there a
    library call that allows millisecond resolution alarms?

    Chris.
    --
    http://www.minixtips.com


  2. Re: Alarms

    Chris Double wrote:
    > The 'alarm' function allows a time period in seconds. Is there a
    > library call that allows millisecond resolution alarms?


    Hi,

    (my guess)

    It is impossible to achieve what you want directly because there is no
    such "system call" which would enable you to do that.

    The current system call `alarm' is actually a library function compiled
    to the `libc'. Its definition can be found in

    /usr/src/lib/posix/_alarm.c

    (just look at Makefile.in and you will see that those functions will be
    compiled to `libc' which in turn is attached to all user space
    programs).

    the `alarm' function does nothing more than sends a message of type
    ALARM to the process MM which is actuall PM_PROC_NR i.e. a process
    manager.

    There is a `do_alarm' function in PM which is invoked in response to
    this message. It uses `set_alarm'. Obviously, timers can be scheduled
    with tick precision. However, that capability is not exposed to the
    outside world.

    It might be an interesting exercise to add a system call which would
    enable that. I think it could be done.


  3. Re: Alarms


    > It might be an interesting exercise to add a system call which would
    > enable that. I think it could be done.


    When adding system calls, does the assembly need to be added as well?
    I've seen the directory of .s files that correspond to system library
    ..c files, and it's not clear to me when they're necessary.


  4. Re: Alarms

    All,

    > When adding system calls, does the assembly need to be added as well?
    > I've seen the directory of .s files that correspond to system library
    > .c files, and it's not clear to me when they're necessary.


    It's a hack to preserve function implementations, even when the user
    application has redefined them. For instance, if someone doesn't use
    write(), but uses stdio, he could unknowingly redefine write(). This
    breaks stdio, which needs write() internally.

    That's why write() is an assembly stub that's safe to redefine, which
    simply jumps to the real implementation, _write().

    stdio library code calls the real write implementation, _write(), so it
    keeps working even if write() is redefined.


    So it's necessary to do this when the function is used internally. But
    it's done almost everywhere to be safe.

    About the original question - such a function would be setitimer(), but
    it hasn't been implemented in minix (yet).

    =Ben



  5. Re: Alarms

    In article <1151424058.757376.142510@j72g2000cwa.googlegroups. com>,
    David.Stanford@gmail.com wrote:
    >
    >> It might be an interesting exercise to add a system call which would
    >> enable that. I think it could be done.

    >
    >When adding system calls, does the assembly need to be added as well?
    >I've seen the directory of .s files that correspond to system library
    >.c files, and it's not clear to me when they're necessary.


    The basic idea is that when for example the function fopen needs to call
    open, it can't just call open because the application may have defined its
    own open function.

    In general, library functions that are part of the C standard cannot assume
    that identifiers in the POSIX standard are reserved.

    Making calls that are used in the library available with a leading underscore
    and providing an assembler jump solves this problem.

    Unfortunately, there is no consistency check for this. So it is quite possible
    that lot's of library function depend on functions in the application's
    namespace.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  6. Re: Alarms

    "Ben Gras" wrote:
    > It's a hack to preserve function implementations, even when the user
    > application has redefined them.


    And a very convenient one at that.. Actually, could you do the same for
    'select'? That would help me quite a bit

    > About the original question - such a function would be setitimer(), but
    > it hasn't been implemented in minix (yet).


    Indeed, it's not very hard to add it though; for the pthreads porting
    project I'm working on, I've already written a patch that adds the
    ITIMER_REAL part of setitimer - unfortunately, I can't release it here just
    yet. I'm currently considering whether it's worth adding support for
    ITIMER_VIRTUAL and ITIMER_PROF to it as well, seeing as they would add quite
    some clutter to the kernel and don't seem to be used a lot...

    Kind regards,
    David



  7. Re: Alarms

    All,

    > And a very convenient one at that.. Actually, could you do the same for
    > 'select'? That would help me quite a bit


    Sure. It's in CVS now.

    =Ben



  8. Re: Alarms

    Thanks!

    Kind regards,
    David



  9. Re: Alarms

    D.C. van Moolenbroek wrote:
    > Indeed, it's not very hard to add it though; for the pthreads porting
    > project I'm working on, I've already written a patch that adds the


    That's great! It's porting code that uses ITIMER that brought the
    question up for me.

    Chris.
    --
    http://www.minixtips.com


  10. Re: Alarms

    I am not very good at C or programming so I am wondering a few things.

    I am looking at _open.c file and see a line that redefines open:

    #define open _open

    The prototype in fcntl.h is:

    _PROTOTYPE( int open, (const char *_path, int _oflag, ...));

    So the redefinition must happen after the typechecking?

    What happens if my userprogram calls open, when it's real name turns
    out to be _open?

    Thank you


  11. Re: Alarms

    All,

    > I am looking at _open.c file and see a line that redefines open:
    >
    > #define open _open
    >
    > The prototype in fcntl.h is:
    >
    > _PROTOTYPE( int open, (const char *_path, int _oflag, ...));
    >
    > So the redefinition must happen after the typechecking?
    >
    > What happens if my userprogram calls open, when it's real name turns
    > out to be _open?


    The name 'open' is only redefined to '_open' within that file. The
    #define happens so the prototype and function declaration match. So
    the implementation of open() is in the C _open() function.

    What is normally called when you do an open() is in syscall/open.s:

    ..sect .text
    ..extern __open
    ..define _open
    ..align 2

    _open:
    jmp __open

    So this only calls the C _open() function (defined in open.c).

    When open() is redefined, this function above is overridden, but
    _open() is still there.

    The confusing thing is that C prefixes all symbols with an underscore
    itself, too, visible from assembly. So what is _open() in C, is
    referenced in assembly as __open.

    I know, confusing. But there's a point to it.

    =Ben



  12. Re: Alarms


    >
    > The name 'open' is only redefined to '_open' within that file. The
    > #define happens so the prototype and function declaration match. So
    > the implementation of open() is in the C _open() function.
    >


    So since there is no prototype for the _open() version of open() you
    rely on programmers to do it right then with the parameters?


  13. Re: Alarms

    All,

    > So since there is no prototype for the _open() version of open() you
    > rely on programmers to do it right then with the parameters?


    There is, indeed, no prototype for _open(). _open.c #defines open as
    _open for this reason, before the prototype gets parsed (so _open()
    does get a prototype). Other files that use _open() could do the same
    thing. I notice freebsd has a file that defines functions
    as their _*() variants, possibly the reason for this is to make the
    above more painless.

    =Ben



+ Reply to Thread