public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ppetru@ppetru.net (Petru Paler)
To: Dan Kegel <dank@kegel.com>
Cc: Christopher Smith <x@xman.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Michael Elkins <me@toesinperil.com>, Zach Brown <zab@zabbo.net>
Subject: Re: sigopen() vs. /dev/sigtimedwait
Date: Fri, 3 Aug 2001 18:38:53 -0700	[thread overview]
Message-ID: <20010803183853.H1080@ppetru.net> (raw)
In-Reply-To: <3B6B50C4.D9FBF398@kegel.com>
In-Reply-To: <3B6B50C4.D9FBF398@kegel.com>

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

  reply	other threads:[~2001-08-04  1:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-04  1:32 sigopen() vs. /dev/sigtimedwait Dan Kegel
2001-08-04  1:38 ` Petru Paler [this message]
2001-08-04  2:10   ` Dan Kegel
2001-08-04  3:04     ` Could /dev/epoll deliver aio completion notifications? (was: Re: sigopen() vs. /dev/sigtimedwait) Dan Kegel
2001-08-04  5:18       ` Zach Brown
2001-08-04  6:27         ` Dan Kegel
2001-08-23 21:17       ` Could /dev/epoll deliver aio completion notifications? (was: Davide Libenzi
  -- strict thread matches above, loose matches on Subject: below --
2001-08-07 14:20 sigopen() vs. /dev/sigtimedwait Erich Nahum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010803183853.H1080@ppetru.net \
    --to=ppetru@ppetru.net \
    --cc=dank@kegel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@toesinperil.com \
    --cc=x@xman.org \
    --cc=zab@zabbo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox