From: Daniel Hilst Selli <danielhilst@gmail.com>
To: "linux-c-programming@vger.kernel.org"
<linux-c-programming@vger.kernel.org>
Subject: Re: Show application performance/errors from pseudo file
Date: Thu, 23 Oct 2014 17:09:03 -0200 [thread overview]
Message-ID: <5449524F.1000206@gmail.com> (raw)
In-Reply-To: <54416747.2010108@gmail.com>
On 10/17/2014 04:00 PM, Daniel Hilst Selli wrote:
> On 10/17/2014 03:59 PM, Daniel Hilst Selli wrote:
>> On 10/16/2014 05:31 PM, Yichao Yu wrote:
>>> Resend as plain text.
>>>
>>> On Thu, Oct 16, 2014 at 4:01 PM, Yichao Yu <yyc1992@gmail.com> wrote:
>>>>
>>>>
>>>> On Thu, Oct 16, 2014 at 3:50 PM, Daniel Hilst Selli <danielhilst@gmail.com>
>>>> wrote:
>>>>>
>>>>> I'm writing a new application and would be nice to have a pseudo file
>>>>> showing its status, just the way that procfs does with kernel.
>>>>> I'm looking for sugestions, I want to `cat' files contents and have
>>>>> something similar to /proc/meminfo
>>>>>
>>>>> First I think using named pipes, but, AFAIK, pipes would retain data
>>>>> writed until someone read it, what I thought is a kind of read
>>>>> hook that only show data when asked for. Here are a few requisites,
>>>>>
>>>>> - Don't retain data
>>>>> - Don't generate disk I/O
>>>>> - Vanish when application stops
>>>>> - Work with a simple cat or something similar..
>>>>
>>>>
>>>> You should have a look at fuse[1].
>>>>
>>>> [1] http://fuse.sourceforge.net/
>>>>
>>>>>
>>>>>
>>>>> With that in mind I think about using unix domain sockets.. it seems to
>>>>> fit all requisites, for
>>>>> the fourth requisite I could use netcat, that is almost cat,
>>>>>
>>>>> Cheers
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-c-programming" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>
>> Seems god, a little overkill for so simple stuff but adds nice features, I'm taking
>> a look on further options..
>>
>> Cheers
> good*
Looking further I found that named pipes will block on open() calls, until
the other end open it too. So I still can implement this with named pipes.
Here is the pseudo code implementation I use. (Yes I'm using threads)
void *stats_handler(void *unused)
{
for (;;) {
int fd = open(FIFO_PATH, O_WRONLY); /* should block here */
/* handle open error */
write(fd, statistics_buffer, statistics_buffer_len);
close(fd);
sleep(1); /* avoid flooders :-P */
}
}
void stats_init(void)
{
pthread_t stat_id;
mkfifo(FIFO_PATH, 0755);
/* handle mkfifo errors */
pthread_create(&stat_id, NULL, stats_handler, NULL);
}
int main(void)
{
...
stats_init();
...
}
After that I can just `cat FIFO_PATH' to see my statistics :D
Thanks for all and best regards!
prev parent reply other threads:[~2014-10-23 19:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 19:50 Show application performance/errors from pseudo file Daniel Hilst Selli
2014-10-16 20:00 ` mspiegelmock
[not found] ` <CAMvDr+T54gR3APzCOyZczvCTZs=FvHhsCA0VkZAVJR3BQdeT+w@mail.gmail.com>
2014-10-16 20:31 ` Yichao Yu
2014-10-17 18:59 ` Daniel Hilst Selli
2014-10-17 19:00 ` Daniel Hilst Selli
2014-10-23 19:09 ` Daniel Hilst Selli [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=5449524F.1000206@gmail.com \
--to=danielhilst@gmail.com \
--cc=linux-c-programming@vger.kernel.org \
/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.