• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 227
  • Last Modified:

Program getting too high of a priority

I have a packet sniffer that uses libpthread and libpcap. There is one while(1) loop in one thread, but I call a sleep(300) at the beginning of the loop. The next thread basically just sets up the callback for libpcap. I noticed that when doing a 'top' listing, my threads are all listed at the top of the list. I am using the default scheduling for the threads. I noticed that when doing a tcpdump, it almost never gets put at the top of the list. How can I reduce the priority of my threads without dropping packets?

1 Solution
>How can I reduce the priority of my threads without dropping packets?

Unless you are facing some problems due to this issue ,i.e. unless it is affecting your functionality, I would suggest that you leave it alone.

Also, if you did not explicitly set the scheduling and priority of your threads, they have the same default priority as almost every other process.
dignifiedAuthor Commented:
That is what I thought too. I just don't understand why they would be having such a higher priority than tcpdump when they do almost the same thing. and use the same library.
It could be that tcpdump sets itself at a lower priority but most likely there is no priority isse involved here. What you see in top table is periodic snapshot and the sleeping task is anyway never in runnable queue so it will not execute at all !!! System may keep a tab on time at which to wake it up and updating a counter, but thats about all.
Instead of using 'sleep' in the while(1) loop, use 'select' or 'pselect' system call on the socket descriptor. That way you can make sure that you will not drop packets.
 It is not because of higher priority, but because of the infinite loop, your process uses a lot of CPU time even when there is no packets arriving and hence listed above tcpdump in top.  By using 'select' or 'pselect', your process will be blocked waiting for packets in the socket descriptor and hence won't utilize the CPU time.
I you're using pcap (presumably opened with pcap_open_live), if you have your main loop as follows:
      const u_char *uchar;
      struct pcap_pkthdr packet;
      while ((uchar = pcap_next(pcap, &packet))) {
      //... process packet
it does not use up any CPU unless you're getting LOTS of ethernet packets and doing heavy processing on them in that loop. pcap_next effectively does a select internally, so the call only returns when a packet arrives to 'wake' your process in the linux kernel process scheduler.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Train for your Pen Testing Engineer Certification

Enroll today in this bundle of courses to gain experience in the logistics of pen testing, Linux fundamentals, vulnerability assessments, detecting live systems, and more! This series, valued at $3,000, is free for Premium members, Team Accounts, and Qualified Experts.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now