Lines Matching refs:it

77 most likely a bug as it re-initializes the queue to an empty queue and
105 For a thread of execution to wait for some concurrent work to finish, it
120 immediately as all dependencies are satisfied if not it will block until
124 so it can only be called safely when you know that interrupts are enabled.
125 Calling it from hard-irq or irqs-off atomic contexts will result in
162 while waiting it will return -ERESTARTSYS; 0 otherwise.
168 (in jiffies). If timeout occurs it returns 0 else the remaining time in
178 TASK_INTERRUPTIBLE. If a signal was received it will return -ERESTARTSYS;
179 otherwise it returns 0 if the completion timed out or the remaining time in
183 designated tasks state and will return -ERESTARTSYS if it is interrupted or
203 achieved calls complete() to signal exactly one of the waiters that it can
227 Signaling completion from hard-irq context is fine as it will appropriately
228 lock with spin_lock_irqsave/spin_unlock_irqrestore and it will never sleep.
235 queue but rather returns false if it would need to enqueue (block) the thread,
236 else it consumes one posted completion and returns true.
240 Finally, to check the state of a completion without changing it in any way,