summaryrefslogtreecommitdiffstats
path: root/sys/kern/kern_timeout.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* tweak timeout_del so it can tell the caller if it actually did remove adlg2011-05-101-2/+7
| | | | | | | | | | | | | | | | timeout or not. without this it is impossible to tell if the timeout was removed or if it is just about to run. if the caller of timeout_del is about to free some state the timeout itself might use, this could lead to a use after free. now if timeout_del returns 1, you know the timeout wont fire and you can proceed with cleanup. how you cope with the timeout being about to fire is up to the caller of timeout_del. discussed with drinking art and art, and most of k2k11 ok miod@
* Get rid of __HAVE_GENERIC_SOFT_INTERRUPTS now that all our platforms support it.kettenis2009-11-041-3/+2
| | | | ok jsing@, miod@
* Constipate the second argument to timeout_add_*(). Also, useguenther2009-06-021-6/+6
| | | | | | | nitems() in two places instead of coding the array size and fix a spot of whitespace. ok miod@ blambert@
* put back r1.25 (poisoning chain pointers after removing items from themiod2009-03-031-1/+4
| | | | wheel). This was safe, except for osiop bugs.
* Add timeout_add_msec(), for timeouts in milliseconds.blambert2008-10-221-1/+13
| | | | | | Idea and original patch mk@ ok mk@, krw@
* Don't lock timeouts in db_show_callout.art2008-07-141-3/+1
| | | | | | | | All cpus are stopped and this cpu blocks all interrupts. It doesn't make sense to grab locks that ddb can then jump past with longjmp. Noticed by Pierre Riteau. I just forgot about the bug until reminded today.
* Add timeout_add_{tv,ts,bt,sec,usec,nsec} so that we can add timeoutsblambert2008-07-111-1/+67
| | | | | | | | | in something other than clock ticks. From art@'s punchlist and (for the time being) not yet used. "you're doing it wrong" art@,ray@,otto@,tedu@ ok art@
* Revert 1.25 and do not use _Q_INVALIDATE on timeout structures; beingmiod2008-01-201-4/+1
| | | | | | subtly different from CIRCLEQ, it is possible, when emptying the whole timeout chain, to end up with CIRCQ_EMPTY being false, and bad things happen. Back to the drawing board...
* Sprinkle some _Q_INVALIDATE love for timeout structures as well; ok otto@miod2006-07-191-1/+4
|
* back out my last commit.dlg2006-04-211-6/+1
| | | | | | | | | | | | art pointed out that timeout_set is the initializer of timeout structs. this means that the ONQUEUE flag could be set when timeout_set is given freshly allocated memory. my commit suddenly introduced the requirement that you bzero a timeout before initialising it. without the bzero we could generate false positives about the timeout being already queued. art did produce a diff that would walk the queues when the flag was set to see if it really was in the lists, but deraadt considers this too much of a hit.
* if you go timeout_set, timeout_add, and then timeout_set again you candlg2006-04-181-1/+6
| | | | | | | | screw up the queues that tie all the timeouts together. this makes us panic if we detect that happening. its a lot easier to debug that the weird side effects of broken timeout queues. ok mickey@ kettenis@ deraadt@ pedro@
* when panicing from timeout_add being < 0, print the value; ok miodderaadt2004-12-281-2/+2
|
* simplify slightly, kill lvalue weirdness that's not ANSI C.espie2004-12-121-8/+9
| | | | okay nordin@
* Diff from art@:grange2004-11-101-2/+9
| | | | | | | | | Update ticks in timeout_hardclock_update to avoid errors in hardclock (this is the third time we mess up here). ticks is only used for timeouts anyway. At the same protect updating ticks with timeout_mutex and be slightly more paranoid in timeout_hardclock_update. ok tdeval@ miod@
* The timeout wheels are manipulated by hardclock that's not protected withart2004-07-201-30/+19
| | | | biglock. We need to protect them with a mutex.
* Two term license with approval from nordin@art2003-06-031-5/+2
|
* Typos; from Julien Bordet <zejames@greyhats.org>grange2003-05-171-2/+2
| | | | Close PR 3262
* diff from nordin@ to prevent wraparound on long uptime machines.tedu2003-04-131-2/+2
| | | | ok art@ deraadt@ miod@ tdeval@
* - Lock the timeout wheel after the diagnostic checks.art2002-12-081-3/+4
| | | | - show timeout_todo in the ddb command.
* First round of __P removal in sysmillert2002-03-141-2/+2
|
* Make rescheduling to a later time faster. ok art@nordin2002-02-151-8/+18
|
* New scalable implementation with constant time add and delete. ok deraadt@nordin2001-12-221-122/+151
|
* Rename timeout_init to timeout_startup to deconfuse a bit.art2001-09-121-2/+2
|
* Remove even more leftovers from old timeouts.art2001-08-231-9/+1
|
* Remove the old timeout legacy code.miod2001-08-231-64/+1
|
* Add some DIAGNOSTIC checks that panic on some of the common mistakes.art2001-03-281-7/+31
|
* Triggered mechanism allows a handler to figure out whether a givencsapuntz2001-03-151-1/+4
| | | | timeout is actually executing.
* typo (incidentally, removed a bogus -k in the cvs file, the updateespie2001-02-161-2/+2
| | | | will trigger $OpenBSD$ fill-in)
* timeout_add: Remove the right timeout when we see that it is on the list.art2000-06-201-2/+2
|
* from art@:mickey2000-05-081-2/+9
| | | | | | | in timeout_hardclock_update() check out if there is anything in the timeout queue before calculating the return value. thanks to Adam Rogoyski <rogoyski@cs.utexas.edu> for debugging and testing help.
* Provide methods to check if a timeout was initalized and if it is scheduled.art2000-03-231-3/+3
|
* Preserve the FIFO order of issued timeouts.art2000-03-231-2/+2
|
* New API for timeouts. Replaces the old timeout()/untimeout() API andart2000-03-231-0/+300
makes it the callers responsibility to allocate resources for the timeouts. This is a KISS implementation and does _not_ solve the problems of slow handling of a large number of pending timeouts (this will be solved in future work) (although hardclock is now guarateed to take constant time for handling of timeouts). Old timeout() and untimeout() are implemented as wrappers around the new API and kept for compatibility. They will be removed as soon as all subsystems are converted to use the new API.