The other obvious problem is that if there are contenders on the semaphore, the semaphore may well not remain acquirable between the return from select and the call to actually acquire the semaphore.
What I'd think you need is a "device" that you open, then attach a semaphore to (with an ioctl()?), then you would write increment/decrement actions to the device file descriptor and it would reply with the results. By making the write and read actions be "normal" and "atomic" you end up with normal produce/consume file operations and so normal interaction with poll/select. I would imagine [off the top of my head] that each device node would have to have some kind of tasklet-like (but blockable) context that could wait for the semaphore in a non-blocking way. (Actually I'd imagine a reverse hook in the semaphore itself that would contain a linked-list of inactive tasklet references which would each be activated on a suitable semaphore operation (increment). The short version is that the "available" state must be atomic with the actual decrement operation or you will probably end up blocking in the decrement after the select() anyway. Once you factor that in, all sorts of more-classic models suggest themselves. Rob White, Casabyte, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
