difference between select, poll and epoll

Which one would you like to use select, poll or epoll? and why??

Any how I have to use only that is supported by my system.

But if all are supported than rank will be epoll, poll and last select in ascending order.

Because there are lots of pros and cons for all three.

fds stands for file descriptors here.

1.

       In select and poll before going to call of select and poll, you have to copy fds and their events from user space to kernel space every time. And to copy or register this events, you have to loop the fds every time also. So its a big overhead.

      But in epoll, you just have to copy fds and events  from user space to kernel space only ones before going into epoll_wait call. So it saves two things looping and coping to user space to kernel space in every next epool_wait call. So its a big advantage.

2.

      In select and poll , after coming from select and poll, you again have to loop all fds and have to check their events. So even if fd's events is not set, you also have to check it. So again its a big over head.

     But in epoll, after coming from epoll call, it gives you list of fds which have events. So you have to loop only those fds who have events but not all fds. So it saves much time.

3.

      epoll works with signalfd, timerfd, eventfd.

4.  

      select is not scalable because the fd_set size (probably your system may have limit to 1024) is limited in our system.

      But in case of poll and epoll, they are scalable.

5.

     In select you have to give read , write and error descriptors to separate fd_set. So You have to loop all  three to check for events.

     But in case of poll  it is in revents of pollfd sturcture and in epoll it is in events of epoll_event structure. So you do not have to loop separately.

6.

     Biggest disadvantage of epoll is that it is not supported by all system and it is not that much portable like select and poll. But if my system supports epoll, I will go for it.

<Sumit kakadiya>

Find out your machine is little endian or big endian by c program - linux

There are lots of ways available on net to find out machine is little endian or big endian.

But the way I am showing is to find out endianess by program that takes optimum memory.

The program will find it just by 2 bytes, as follow

#include <stdio.h>
#include <inttypes.h>

struct abc {
    union {
        int16_t a;
        char c[sizeof(int16_t)];
    };
};

int
main() {
    struct abc abc;
    abc.a = 1;

    if(abc.c[0] == 1) {
        printf("Machine is little endian.\n");
    } else {
        printf("Machine is big endian\n.");
    }

    return 0;
}


<Sumit Kakadiya>                                                                                                                                                                   

C programming-- throughput increment -decrement by little take care

"Optimum space maximum throughput"

Suppose you are creating on structure having fixed sized for example:

1.
struct abc {
     int a;
     char c[50];
};

2.
you can also write the same as
struct abc {
    int a;
    char *c;
};   and you will malloc like c= malloc(50);

and you want to do something like
struct abc *a=malloc(sizeof(struct abc));

So which way is better?

Yes it depends on application but if your structure size is fixed means any how your structure have int a + 50 bytes for variable in that case , you should go for 1.(first) implementation.

Why????

Because when you go for first implementation, whole memory will be continues, so OS(operating system) will load all memory in same page.  So there will be very less page-fault.

While in second implementation, it may possible that when you do c=malloc(50), memory of c will be allocated  in other page, so to access c OS may have page-faults.   Even you will also have to do extra system call malloc for allocating memory to variable c. So it would minimize your throughput.

Another thing is that you are saving space of sizeof(char*)  in implementation 1.Because in first implementation you are using char c[50]; that requires exactly 50*sizeof(char) bytes.

But in second implementation, you have bytes of sizeof(char *) + (50*sizeof(char));



<Sumit Kakadiya>