RFC: API change for sema_timedwait

From: John Polstra (jdp_at_polstra.com)
Date: 06/12/04

  • Next message: Robert Watson: "Re: RFC: API change for sema_timedwait" 
    Date: Sat, 12 Jun 2004 12:15:21 -0700 (PDT)
To: freebsd-arch@freebsd.org

    Before 5.x becomes -stable, I'd like to change the API of
    sema_timedwait(9). This function is used in only 3 places in the
    kernel, all in "dev/ips/ips_commands.c".

    Currently, sema_timedwait returns 0 if the operation fails due to a
    timeout. On success, it returns a non-zero value. This is precisely
    the opposite of the standard convention in the kernel, where 0 means
    success and a non-zero value (taken from <sys/errno.h>) means failure.
    The convention exists because most functions can succeed in only one
    way but can fail in several different ways.

    The reason I care about this is because I'd like to add new functions
    sema_wait_sig() and sema_timedwait_sig() which can be interrupted
    by a signal. Then sema_timedwait_sig could fail in two different
    ways: as a result of a timeout or as a result of a signal. If these
    functions returned proper errno values on failure, it would be easy to
    distinguish between the two failure cases.

    This change would also make the return values of sema_timedwait,
    sema_wait_sig, and sema_timedwait_sig consistent with the analogous
    condition variable operations cv_timedwait, cv_wait_sig, and
    cv_timedwait_sig and with tsleep and msleep.

    Does this change sound OK to you folks?

    John
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Robert Watson: "Re: RFC: API change for sema_timedwait"

    Relevant Pages

    • kernel: Bad page state in process cc1
      ... We were running the 2.6.16.17 kernel for a few months. ... Trying to fix it up, but a reboot is needed ... and so the build would fail. ... the build after every failure. ...
      (comp.os.linux.development.system)
    • Re: Thread Pre-Emption Question . . .
      ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... the correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Thread Pre-Emption Question . . .
      ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Importance of Failure
      ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
      (sci.math)
    • Re: Importance of Failure
      ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
      (sci.crypt)