lkml.org 
[lkml]   [2013]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to control persistency
On Tue, Aug 27, 2013 at 01:54:22PM +0200, Robert Richter wrote:
> I got another idea for this, what about UNCLAIM and CLAIM? It is
> exactly, what it is. A process unclaims an event telling it doesn't
> care anymore. Another process comes and claims the event, meaning the
> process wants the event no longer to be shared with others and being
> released after closing.

This still doesn't pan out because with claiming the event, you state
that the event is *owned* by this process but with persistent events
we want to be able to state that they can have multiple users and thus
multiple buffer consumers, concurrently.

> > > 3. ioctl DETACH from it so that it is "forked in the background" so to
> > > speak, very similar to a background job in the shell.
>
> With 'detach' we move the event into the 'background' so that it is
> still available after opening.

Ok, maybe ATTACH/DETACH is not the perfect naming for this after all.
Maybe when we want to state the fact that the event is going to continue
existing after closing the buffer consumer, we want to do ioctl(event,
DONT_DESTROY) and when we want to actually get rid of it, one of the
process does ioctl(event, DESTROY).

Which reminds me, what do we do when one process destroys the event but
there are other consumers accessing it concurrently? Refcounting?

Thanks.

--
Regards/Gruss,
Boris.


\
 
 \ /
  Last update: 2013-08-27 15:01    [W:0.092 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site