Re: [RFC][PATCH] Kernel thread signal handling.

[David Woodhouse]

On Mon, 2003-10-13 at 04:02 -0700, Andrew Morton wrote:
> Sigh.  Using signals to communicate with kernel threads is evil.  It keeps
> on breaking and each site does it differently and we've had plenty of bugs
> due to this practice.

The point in cleaning up allow_signal() et al. is that it gets simple
and it stops breaking. Not that I recall having signal problems with the
JFFS2 garbage collection thread other than this one, mind you.

> Is there no way in which jffs2 can be weaned off this obnoxious habit?

We have a kernel thread which performs garbage collection on our
log-structured file system, to make space ahead of time for writes to
happen. It's purely an optimisation -- we also perform garbage
collection just-in-time in the context of a process which wants to
actually _write_, if there's no free space but some could be made.

This garbage collection involves reading, writing and erasing the flash.
It takes CPU time and power. Sometimes userspace wants it to stop
happening in the background; sometimes userspace wants it to resume
again.

So userspace sends SIGSTOP, SIGCONT and SIGKILL to the garbage
collection thread and all of them have the expected effect. 

Since we handle these signals anyway, the normal wakeup of the GC thread
when the amount of free space changes is also done by SIGHUP, which
userspace can also send to trigger a single pass.

I don't any the benefit in changing this practice.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/