On Mon, Oct 16, 2006 at 02:59:48AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >One can set number of events before the syscall and do not remove them
> >after syscall. It can be updated if there is need for that.
>
> Nobody doubts that it is possible. But it is
Evgeniy Polyakov wrote:
One can set number of events before the syscall and do not remove them
after syscall. It can be updated if there is need for that.
Nobody doubts that it is possible. But it is
a) potentially much expensive
and
b) an alien concept
to have the signal mask to set durin
On Sun, Oct 15, 2006 at 03:43:39PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >In context you have cut, one updated signal mask between calls to event
> >delivery mechanism (using for example signal()), so it has exactly the
> >same price.
>
> No, it does not. I
Evgeniy Polyakov wrote:
In context you have cut, one updated signal mask between calls to event
delivery mechanism (using for example signal()), so it has exactly the
same price.
No, it does not. If the signal mask is recomputed by the program for
each new wait call then you have a lot more w
On Thu, Oct 05, 2006 at 07:45:23AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > And you can add/remove signal events using existing kevent api between
> > calls.
>
> That's far more expensive than using a mask under control of the program.
In context you have cu
Evgeniy Polyakov wrote:
> And you can add/remove signal events using existing kevent api between
> calls.
That's far more expensive than using a mask under control of the program.
> And creating special cases for usual events is bad.
> There is unified way to deal with events in kevent -
> add/r
On Wed, Oct 04, 2006 at 10:20:44AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > It is completely possible to do what you describe without special
> > syscall parameters.
>
> First of all, I don't see how this is efficiently possible. The mask
> might change from
Evgeniy Polyakov wrote:
> It is completely possible to do what you describe without special
> syscall parameters.
First of all, I don't see how this is efficiently possible. The mask
might change from call to call.
Second, hasn't it sunk in that inventing new ways to pass parameters is
bad? Pro
On Wed, Oct 04, 2006 at 12:33:25AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > When we enter sys_ppoll() we specify needed signals as syscall
> > parameter, with kevents we will add them into the queue.
>
> No, this is not sufficient as I said in the last mail.
Evgeniy Polyakov wrote:
> When we enter sys_ppoll() we specify needed signals as syscall
> parameter, with kevents we will add them into the queue.
No, this is not sufficient as I said in the last mail. Why do you
completely ignore what others say. The code which depends on the signal
does not h
On Tue, Oct 03, 2006 at 11:10:51PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> [Bah, sent too eaqrly]
>
> On 9/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >The only two things missed in patchset after his suggestions are
> >new POSIX-like interface, which I personally consider as
On Tue, Oct 03, 2006 at 11:09:15PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> On 9/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >The only two things missed in patchset after his suggestions are
> >new POSIX-like interface, which I personally consider as very unconvenient,
>
> This
[Bah, sent too eaqrly]
On 9/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
The only two things missed in patchset after his suggestions are
new POSIX-like interface, which I personally consider as very unconvenient,
This means you really do not know at all what this is about. We
already h
On 9/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
The only two things missed in patchset after his suggestions are
new POSIX-like interface, which I personally consider as very unconvenient,
This means you really do not know at all what this is about. We
already have these interfaces. S
On Tue, Oct 03, 2006 at 09:50:09PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> On 9/27/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> \> I have been told in private what is signal masks about - just to wait
> >until either signal or given condition is ready, but in that case just
> >add
On 9/27/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
\> I have been told in private what is signal masks about - just to wait
until either signal or given condition is ready, but in that case just
add additional kevent user like AIO complete or netwrok notification
and wait until either reques
On Wed, Sep 20, 2006 at 01:35:47PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
>
> Generic event handling mechanism.
>
> Consider for inclusion.
I have been told in private what is signal masks about - just to wait
until either signal or given condition is ready, but in that case just
a
On Tue, Sep 26, 2006 at 04:54:16PM +0100, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> > > Generic event handling mechanism.
> > >
> > > Consider for inclusion.
> >
> > Ulrich's objections sounded substantial, and afaik remain largely
> > unresolved. How do we sort this out?
>
> I haven't s
On Fri, Sep 22, 2006 at 12:22:07PM -0700, Andrew Morton wrote:
> On Wed, 20 Sep 2006 13:35:47 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > Generic event handling mechanism.
> >
> > Consider for inclusion.
>
> Ulrich's objections sounded substantial, and afaik remain largely
> unreso
On Fri, Sep 22, 2006 at 12:22:07PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> On Wed, 20 Sep 2006 13:35:47 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > Generic event handling mechanism.
> >
> > Consider for inclusion.
>
> Ulrich's objections sounded substantial, and afaik re
On Wed, 20 Sep 2006 13:35:47 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Generic event handling mechanism.
>
> Consider for inclusion.
Ulrich's objections sounded substantial, and afaik remain largely
unresolved. How do we sort this out?
-
To unsubscribe from this list: send the line "
Generic event handling mechanism.
Consider for inclusion.
Changes from 'take18' patchset:
* use __init instead of __devinit
* removed 'default N' from config for user statistic
* removed kevent_user_fini() since kevent can not be unloaded
* use KERN_INFO for statistic output
Changes from 't
22 matches
Mail list logo
