process information

process information

[Matías Aguirre]

a little question, is there any way to get a process current children count?

thanks

-- 
Matías Aguirre
-
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

Re: process information

[sumit kalra]

"ps --ppid <parent-pid>" may help you.
man ps

Regards,
Sumit
--- Matías Aguirre <matiasaguirre@gmail.com> wrote:

> a little question, is there any way to get a process
> current children count?
> 
> thanks
> 
> -- 
> Matías Aguirre
> -
> 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
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
-
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

Re: process information

[Luiz Fernando Capitulino]

Hi Matías,

Matías Aguirre wrote:
> a little question, is there any way to get a process current children count?

 Yes, there is. But I can only think in a 'brute force' way: you can scan the
/proc file-system.

 Let's say you want to know how many children the X process has. You open
each '/proc/PID/status' and read the 'Ppid' field. If it's equals X, you
count it.

 As I said, it's ugly, but I cannot think in another solution.

 You can try to read the code of 'pstree' program, but I guess it
scans the /proc file-system too.

-
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

Re: process information

[Matías Aguirre]

On 7/7/05, Luiz Fernando Capitulino <lcapitulino@conectiva.com.br> wrote:
> Hi Matías,

Hi Luiz

>  Yes, there is. But I can only think in a 'brute force' way: you can scan the
> /proc file-system.
[...]

Yes, I was thinking in that solution, but it doesn't fix in my
situation, my problem is a bit complicated...

I lunch a little process that inicialize a shmem segment (libmm), then
it call a function that's in a library, this function makes a fork and
create a server as the son process (an abyss http server, i'm using
libxmlrpc-c3) and then do an exit(0) in the father, and this unmap the
shmem allocated, this because allocation and deallocation is made by
the next functions:

void __attributte__ ((constructor)) void _init_fn(){
    root_p=getpid();
    MM_create(MM_SIZE,MM_FILE);
    signal(SIGINT|SIGTERM|SIGSEGV|SIGABRT|SIGHUP,_sigint);
}

void __attribute__ ((destructor))  _uninit_fn(){
    if(getpid()==root_p)
        MM_destroy();
}

where root_p is the pid of the process that inicialize every thing, so
when it dies the shmem is deallocated, as you can see, it dies because
the function that lunch the server mekes an exit(0).

So, i'm traying to make a little trick, a first process that create
the shmem and makes a fork, this new son lunch the server, but now I
need to know when the server dies so my process can finish and
deallocate the shmem.

Sorry, but my english is very bad... :)

Thanks

-- 
Matías Aguirre
-
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

Re: process information

[Luiz Fernando Capitulino]

Matías,

Matías Aguirre wrote:

[...]

> So, i'm traying to make a little trick, a first process that create
> the shmem and makes a fork, this new son lunch the server, but now I
> need to know when the server dies so my process can finish and
> deallocate the shmem.

I guess I didn't get the problem here, can't you use SIGCHLD?

> Sorry, but my english is very bad... :)

I did understand you just perfectly, your english isn't worst
than mine.


-
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

x86 Endiannes and libc printf

[Nanakos Chrysostomos]

Hi all,
i am searching for a few hours now the endianness in the x86
environment,and i have the following
snippets of code,which in some places i cant understand.Please help me!!!

endian.c
---------
#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>


int main()
{
        char *filename= "endian.txt";
        unsigned long buf;
        char *k=(char *)&buf;
        int fd;

        fd = open("makis",O_RDONLY);

        read(fd,&buf,4);

        printf("%.4s\n",&buf);
        printf("%p\n",buf);
        printf("&buf: %p %#x %p\n",&buf,*k,k);
        return 0;
}

endian.txt
----------
DBCA


#./read
DCBA
0x41424344
&buf: 0xbffff8b0 0x44 0xbffff8b0
#


In the first printf everything is fine.In the second printf we see that
the 0x44,0x43,0x42,0x41 byte-data is printed in the revserse order,while
we can see
that in memory it is in the right order after the read system call.Why
this happens?Is it being internal in printf???


I tried to explain that with similar approaches like unions, but the same
happens.endian2.c
---------
#include <stdio.h>
#include <unistd.h>

int   main()
{

        union {
                long   s;
                char    c[sizeof(long)];
        } un;

        un.s = 0x41424344;
        if (sizeof(short) == 2) {
                if (un.c[0] == 0x41 && un.c[1] == 0x42)
                        printf("big-endian\n");
                else if (un.c[0] == 0x44 && un.c[1] == 0x43)
                        printf("little-endian\n");
                else
                        printf("unknown\n");
        } else
                printf("sizeof(short) = %d\n", sizeof(short));


        printf("%.4s\n",&(un.s));
        printf("%p\n",(un.s));
        _exit(0);

}



The same as above.Should i assume that an internal operation in printf is
doing this???


I also used the above assembly example,to see what
happens.Memory-to-memory movements (with push & pop) dont inherit the
little-endian way.Is this
happens only from memory-to-register and the opposite????

read.asm
--------
section .bss
buf     resd    1

section .data
        pathname db "makis",0
section .text

global _start

_start:

;open
mov eax,5
mov ebx,pathname
mov ecx,02
int 0x80


;read
mov ebx,eax
mov eax,3
mov ecx,buf
mov edx,4
int 0x80

;write
mov eax,4
mov ebx,1
mov ecx,buf
mov edx,4
int 0x80

;exit
mov eax,1
mov ebx,0
int 0x80


Everything works just fine.Can anynone knows how can i revserse the order
of the data,from 0x44434241 to 0x41424344 into the stack?? Without using
AND and OR.Can
this be done????


The last two examples is the output from gcc,one "fixed" from me to find
out what is in the stack and the other is the default output from the
first example.My example
has been changed only in the printf call from the library,after the read
call,which i suppose is the "black box" to the "problem" i cant
understand...........read.s
------
        .file   "read.c"
        .version        "01.01"
gcc2_compiled.:
                .section        .rodata
.LC0:
        .string "makis"
.LC1:
        .string "%#x\n"
.text
        .align 4
.globl main
        .type    main,@function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        movl    $.LC0, -4(%ebp)
        subl    $8, %esp
        pushl   $0
        pushl   $.LC0
        call    open

        addl    $16, %esp
        movl    %eax, %eax
        movl    %eax, -12(%ebp)
        subl    $4, %esp
        pushl   $4
        leal    -8(%ebp), %eax
        pushl   %eax
        pushl   -12(%ebp)
        call    read

---->Before it was the printf call which retrieves its arguments from the
stack.Which as we can see its different for every conversion specifier..

        movl    $4,%eax
        movl    $1,%ebx
        leal    -8(%ebp),%ecx
        movl    $4,%edx
        int     $0x80


        movl    $1, %eax
        movl    $0,%ebx
        int $0x80
.Lfe1:
        .size    main,.Lfe1-main
        .ident  "GCC: (GNU) 2.96 20000731 (Red Hat Linux 7.3 2.96-110)"



Can someone please help me with that???

Thanks in advance,Chris.

Re: x86 Endiannes and libc printf

[Glynn Clements]

Nanakos Chrysostomos wrote:

> i am searching for a few hours now the endianness in the x86
> environment,and i have the following
> snippets of code,which in some places i cant understand.Please help me!!!
> 
> endian.c
> ---------
> #include <stdio.h>
> #include <fcntl.h>
> #include <sys/types.h>
> 
> 
> int main()
> {
>         char *filename= "endian.txt";
>         unsigned long buf;
>         char *k=(char *)&buf;
>         int fd;
> 
>         fd = open("makis",O_RDONLY);
> 
>         read(fd,&buf,4);
> 
>         printf("%.4s\n",&buf);
>         printf("%p\n",buf);
>         printf("&buf: %p %#x %p\n",&buf,*k,k);
>         return 0;
> }
> 
> endian.txt
> ----------
> DBCA
> 
> 
> #./read
> DCBA
> 0x41424344
> &buf: 0xbffff8b0 0x44 0xbffff8b0
> #
> 
> 
> In the first printf everything is fine.In the second printf we see that
> the 0x44,0x43,0x42,0x41 byte-data is printed in the revserse order,while
> we can see
> that in memory it is in the right order after the read system call.Why
> this happens?Is it being internal in printf???

No. x86 is little-endian, which means that multi-byte integers are
stored in memory with the lowest byte first, e.g. the integer
0x41424344 (1094861636 decimal) is stored 0x44,0x43,0x42,0x41.

> The same as above.Should i assume that an internal operation in printf is
> doing this???

No. It's the way that the CPU reads/writes integers to/from memory.

> I also used the above assembly example,to see what
> happens.Memory-to-memory movements (with push & pop) dont inherit the
> little-endian way.Is this
> happens only from memory-to-register and the opposite????

Yes. Endianness doesn't matter if you are just moving bytes around. It
only matters if you are treating a block of 2/4/8 bytes as a
16/32/64-bit integer.

-- 
Glynn Clements <glynn@gclements.plus.com>