|
Home > Archive > Unix Programming > September 2007 > declaring a function as static..
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
declaring a function as static..
|
|
|
| hello everyone,
i am using a hacked version of the utilities df and du to get the disk
free space and folder size respectively..
when i say hacked i mean i just got the df.c and du.c from core-utils
renamed their main() function to dfmain() and dumain(), commented out
all the printf statements (since i only wanted the numbers ) and i
compiled them along with my code....
problem is df and du as designed for one-off operation, that is the
program runs once, ends and its resources are freed by the OS (cause
it has alot of static declarations as i see in the sources)
on the contrary my program is running in a loop (its a processing
algorithm) so it appears that running the dfmain() or the dumain()
function from my code again and again consumes resources that do not
get freed..
is there a way to sort of declare the whole df.c and du.c as static?
so that they wont be loaded each time in the loop? i mean should i
make each variable and function static in those 2 files? would this
suffice? or is there smth additional / different needed... this is
obviously a non-neat solution... so i am open to suggestions about
acquiring the disk remaining free space and the folder size for my
program...
thank you in advance for your help
nass
| |
| Giorgos Keramidas 2007-09-27, 7:37 pm |
| On Thu, 27 Sep 2007 22:09:58 -0000, nass <athanasios.silis@gmail.com> wrote:
> hello everyone,
> i am using a hacked version of the utilities df and du to get the disk
> free space and folder size respectively..
> when i say hacked i mean i just got the df.c and du.c from core-utils
> renamed their main() function to dfmain() and dumain(), commented out
> all the printf statements (since i only wanted the numbers ) and i
> compiled them along with my code....
>
> problem is df and du as designed for one-off operation, that is the
> program runs once, ends and its resources are freed by the OS (cause
> it has alot of static declarations as i see in the sources)
>
> on the contrary my program is running in a loop (its a processing
> algorithm) so it appears that running the dfmain() or the dumain()
> function from my code again and again consumes resources that do not
> get freed..
>
> is there a way to sort of declare the whole df.c and du.c as static?
Sort of forking a copy and reading the results through a pipe (which can
be _very_ inefficient, depending on the frequency of the forks you plan
to do), no...
We had to do something similar with prstat(1) and vmstat(1) at work, and
we ended up modifying prstat_main() and vmstat_main() to use two sorts
of buffers:
* Long-lived reusable buffers (declared static)
* Short-lived buffers grabbed with malloc() and released with
free() *every* time the respective xxx_main() function runs.
You'll have to do something similar.
| |
|
| On Sep 28, 1:31 am, Giorgos Keramidas <keram...@ceid.upatras.gr>
wrote:
> On Thu, 27 Sep 2007 22:09:58 -0000, nass <athanasios.si...@gmail.com> wrote:
>
>
>
>
> Sort of forking a copy and reading the results through a pipe (which can
> be _very_ inefficient, depending on the frequency of the forks you plan
> to do), no...
>
> We had to do something similar with prstat(1) and vmstat(1) at work, and
> we ended up modifying prstat_main() and vmstat_main() to use two sorts
> of buffers:
>
> * Long-lived reusable buffers (declared static)
>
> * Short-lived buffers grabbed with malloc() and released with
> free() *every* time the respective xxx_main() function runs.
>
> You'll have to do something similar.
hmmm im not sure what was the purpose of each of the 2 buffer
categories...
unless you mean that you actually sort of re-declared all the vmstat
variables...
| |
| Paul Pluzhnikov 2007-09-27, 7:37 pm |
| Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> On Thu, 27 Sep 2007 22:09:58 -0000, nass <athanasios.silis@gmail.com> wrote:
Static in what sense?
[vbcol=seagreen]
> Sort of forking a copy and reading the results through a pipe (which can
> be _very_ inefficient, depending on the frequency of the forks you plan
> to do), no...
Well, you could:
- compile dfmain() into a shared library
- make it use a pool allocator instead of "regular" malloc.
Then, after each dfmain() invocation, free the pool from which
it was allocating (to get rid of dynamically-allocated memory),
and dlclose()/dlopen() the library (to clear its globals).
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Giorgos Keramidas 2007-09-28, 1:30 am |
| On Thu, 27 Sep 2007 23:43:17 -0000, nass <athanasios.si...@gmail.com> wrote:
>On Sep 28, 1:31 am, Giorgos Keramidas <keram...@ceid.upatras.gr> wrote:
>
> hmmm im not sure what was the purpose of each of the 2 buffer
> categories...
The first category was introduced by me after we finished the first part
of the work, and we found that it was all working.
> unless you mean that you actually sort of re-declared all the vmstat
> variables...
The way the Solaris vmstat(1) utility works depends on keeping around a
pair of "kstat snapshots". We could always rely on libumem.so.1 or some
other malloc() implementation that caches freed objects to give us back
precisely the kstat snapshot we released just a second or so ago.
We could also malloc() two kstat snapshots, and reuse them every time we
iterated through vmstat_main(). The snapshots are only used to collect
/some/ kernel information and then thrown away, so we added:
int vmstat_init(void);
int vmstat_fini();
to take care of preallocating any buffers we would keep around while the
program was running, and free them just once before the program exited.
For *very* short-lived objects, we didn't bother to preallocate
anything. It wasn't really worth the development time, and it was
better to spend this time looking for places where memory would be
"leaked" if we simply copied vmstat(1) in its original form.
- Giorgos
| |
| fjblurt@yahoo.com 2007-09-28, 1:30 am |
| On Sep 27, 3:09 pm, nass <athanasios.si...@gmail.com> wrote:
> hello everyone,
> i am using a hacked version of the utilities df and du to get the disk
> free space and folder size respectively..
> when i say hacked i mean i just got the df.c and du.c from core-utils
> renamed their main() function to dfmain() and dumain(), commented out
> all the printf statements (since i only wanted the numbers ) and i
> compiled them along with my code....
>
> problem is df and du as designed for one-off operation, that is the
> program runs once, ends and its resources are freed by the OS (cause
> it has alot of static declarations as i see in the sources)
>
> on the contrary my program is running in a loop (its a processing
> algorithm) so it appears that running the dfmain() or the dumain()
> function from my code again and again consumes resources that do not
> get freed..
>
> is there a way to sort of declare the whole df.c and du.c as static?
> so that they wont be loaded each time in the loop? i mean should i
> make each variable and function static in those 2 files? would this
> suffice? or is there smth additional / different needed... this is
> obviously a non-neat solution... so i am open to suggestions about
> acquiring the disk remaining free space and the folder size for my
> program...
df and du are very simple programs, so it is probably easiest just to
rewrite their functionality.
For df, see the statfs(2) function. The free space on the filesystem
in bytes should be given by f_blocks*f_bsize. If you have a device
name instead of a path, use getmntinfo to find the mount point.
For du, recurse through the given directory. Use opendir/readdir to
open a directory, and call stat on each entry returned. The amount of
space it uses is approximately 512*st_blocks. If it is a directory
(check S_ISDIR(st_mode)), recursively find the size of its contents.
| |
| Rainer Weikusat 2007-09-28, 7:30 am |
| fjblurt@yahoo.com writes:
> On Sep 27, 3:09 pm, nass <athanasios.si...@gmail.com> wrote:
[...]
> df and du are very simple programs, so it is probably easiest just to
> rewrite their functionality.
Why would a "progger" ever "reinvent a wheel" just because the one he
found in his backyard happens to be square?
SCNR
| |
| Scott Lurndal 2007-09-28, 1:24 pm |
| fjblurt@yahoo.com writes:
>For du, recurse through the given directory. Use opendir/readdir to
>open a directory, and call stat on each entry returned. The amount of
>space it uses is approximately 512*st_blocks. If it is a directory
>(check S_ISDIR(st_mode)), recursively find the size of its contents.
>
ftw(3) or nftw(3) are simpler than opendir/readdir/recurse.
scott
|
|
|
|
|