From: Alexander Holler <holler@ahsoftware.de>
To: "Drubin, Daniel" <daniel.drubin@intel.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Jonathan Cameron <jic23@cam.ac.uk>,
"Yuniverg, Michael" <michael.yuniverg@intel.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"Haimovich, Yoav" <yoav.haimovich@intel.com>
Subject: Re: working with IIO
Date: Wed, 28 Aug 2013 14:56:53 +0200 [thread overview]
Message-ID: <521DF395.1060502@ahsoftware.de> (raw)
In-Reply-To: <CE30B71206DDA24CBD6D43D23C236C034D8C69@HASMSX103.ger.corp.intel.com>
Am 22.08.2013 18:26, schrieb Drubin, Daniel:
>>>> So each time a process writes to a IIO sysfs file you want to record
>>>> which value that application wrote. So when I run `for i in `seq 0
>>>> 100000`; do echo $i
>>>>> sampling_frequency; done` I'd end up with a list with one million
>>>>> entries
>>>> which will stay in the list forever.
>>>
>>> No, there is only one entry per PID. Next value that the same process
>> writes will replace the previous one, not create a new entry. An entry will be
>> create only if the write request arrived from a PID currently not in list.
>>>
>>
>> Assume that echo is a /bin/echo, not a shell built-in command.
>
> Then indeed a new entry will be created 100000 times. But before creating a new instance of /bin/echo, the previous one will terminate closing all file descriptors. A device driver would miss this event and thus an ability to remove PID from list only if the framework for some reason chose to ban it from knowing.
Try
sysctl kernel.pid_max
So the list would be likely smaller and reused PIDs will end up with a
funny behaviour. ;)
Regards,
Alexander Holler
prev parent reply other threads:[~2013-08-28 12:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0423FED8EB79934F939F077EAF96DBD717D8025F@HASMSX105.ger.corp.intel.com>
2013-08-21 21:00 ` working with IIO Jonathan Cameron
2013-08-22 11:30 ` Drubin, Daniel
2013-08-22 13:16 ` Lars-Peter Clausen
2013-08-22 13:39 ` Drubin, Daniel
2013-08-22 14:16 ` Lars-Peter Clausen
2013-08-22 14:45 ` Drubin, Daniel
2013-08-22 14:52 ` Lars-Peter Clausen
2013-08-22 15:08 ` Jonathan Cameron
2013-08-22 15:33 ` Drubin, Daniel
2013-08-22 16:15 ` Jonathan Cameron
2013-08-22 16:35 ` Drubin, Daniel
2013-08-23 16:23 ` Jonathan Cameron
2013-08-23 18:37 ` Jonathan Cameron
2013-08-22 15:16 ` Drubin, Daniel
2013-08-22 15:41 ` Lars-Peter Clausen
2013-08-22 15:48 ` Drubin, Daniel
2013-08-22 16:00 ` Lars-Peter Clausen
2013-08-22 16:26 ` Drubin, Daniel
2013-08-22 16:56 ` Lars-Peter Clausen
2013-08-28 12:56 ` Alexander Holler [this message]
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=521DF395.1060502@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=daniel.drubin@intel.com \
--cc=jic23@cam.ac.uk \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=michael.yuniverg@intel.com \
--cc=yoav.haimovich@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.