On Fri, Aug 03, 2001 at 06:32:52PM -0700, Dan Kegel wrote:
> So I'm proposing the following user story:
>
> // open a fd linked to signal mysignum
> int fd = open("/dev/sigtimedwait", O_RDWR);
> int sigs[1]; sigs[0] = mysignum;
> write(fd, sigs, sizeof(sigs[0]));
>
> // memory map a result buffer
> struct siginfo_t *map = mmap(NULL, mapsize, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
>
> for (;;) {
> // grab recent siginfo_t's
> struct devsiginfo dsi;
> dsi.dsi_nsis = 1000;
> dsi.dsi_sis = NULL; // NULL means "use map instead of buffer"
> dsi.dsi_timeout = 1;
> int nsis = ioctl(fd, DS_SIGTIMEDWAIT, &dvp);
>
> // use 'em. Some might be completion notifications; some might be readiness notifications.
> for (i=0; i<nsis; i++)
> handle_siginfo(map+i);
> }
And the advantage of this over /dev/epoll would be that you don't have to
explicitly add/remove fd's?
I ask because yesterday I used /dev/epoll in a project and it behaves *very*
well, so I'm wondering what advantages your interface would bring.
> Comments?
How do you handle signal queue overflow? signal-per-fd helps, but you still
have to have the queue as big as the maximum number of fds is...
Petru
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:31 EST