In-kernel API for tasks, which could wait?
Hello, Current. It was explained to me, that all three GEOM threads (up, down and ctl) could not execute code, which should sleep. It looks sound for up and down, but not for ctl, but it is so now. So, I have question: what should I do if I need to perofrm ONE action, which could block for some time (for example, open file or create ALQ)? I could create thread for this. But it looks strange and too heavy: create thread to call one function once. Maybe, kernel has some API to postpone such task to one, always-running idle thread? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel API for tasks, which could wait?
On Sun, Oct 30, 2011 at 06:54:51PM +0400, Lev Serebryakov wrote: So, I have question: what should I do if I need to perofrm ONE action, which could block for some time (for example, open file or create ALQ)? I could create thread for this. But it looks strange and too heavy: create thread to call one function once. Maybe, kernel has some API to postpone such task to one, always-running idle thread? See taskqueue(9). On the other hand, waiting for the enqueued task to finish is itself the sleepable action. pgpei4uyxuJ1X.pgp Description: PGP signature
Re: In-kernel API for tasks, which could wait?
Hello, Kostik. You wrote 30 октября 2011 г., 19:03:39: See taskqueue(9). On the other hand, waiting for the enqueued task to finish is itself the sleepable action. I'll not wait for finishing. Task will put result to volatile atomic field, and it's all. -- // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
