CODEWITHSUNDEEP
clinuxmultithreadingprocessnetwork-programming
user1944267
user1944267

Reputation: 1637

choosing between process and thread, and inter-process(thread) communication

I want to write a simple UDP server program which use recvfrom() to receive packet for each received packet, the program will process it my original source codes are like:

for(;;){
n = recvfrom(sockfd, mesg, 10000, 0 ptr_sockaddr, &len);
process(mesg);
}

but in this way, if the process() function takes a bit long time, it will influence the recvfrom(). so I need to create a new process or new thread,

  1. which one is better for this scenario? thread or process? why?
  2. how to deal with the inter-process or inter-thread communication, I mean I need to deliver the character string mesg to the new process(or thread). And if the packet receiption is much faster than the processing, what kind buffering method should I use?

if some source code snippets can be provided, that's better!

thanks!

Upvotes: 0

Views: 721

Answers (5)

gby
gby

Reputation: 15218

Process. Then a programming error will tear down a single connection and not the entire server.

For communication you can establish a shared memory region before the fork() between the father and all child processes and sync. using mutex/semaphores.

Upvotes: 0

bahaa
bahaa

Reputation: 195

if the function process() is not returning anything to the parent it's much easier to create a process per message. all you need to do is add if (fork()<=0) return; in the beginning of process() and you don't need to worry about overwriting mesg and ptr_sockaddr.

Upvotes: 0

Martin James
Martin James

Reputation: 24857

Declare some struct to contain the data. Malloc one. Read in a message. Queue off the *struct and immediately malloc, (or depool), another one for the next message. Free, or repool, the *struct after handling in the consumer.

You can do flow control by either:

1) Using a bounded blocking queue, freeing the *struct at the consumer end after handling.

2) Using two unbounded blocking queues - one prefilled with *struct to act as a pool, the other to communicate between the threads. When the recvFrom thread needs a *struct, pop it from the pool. When the consumer has handled a *struct, push it back onto the pool.

Upvotes: 0

David Schwartz
David Schwartz

Reputation: 182769

I would recommend having one thread that loops around recvfrom. When it receives a datagram, have it put that datagram on a queue. You can then have a pool of threads that pull datagrams from the queue and process them.

The usual solution is to have a mutex and a condition variable that protects the queue. Adding an item to the queue works like this:

  1. Acquire the mutex.

  2. Add the item to the queue.

  3. Signal the condition variable.

  4. Release the mutex.

And the threads in the pool do this:

  1. Acquire the mutex.

  2. If there's an item in the queue, skip to step 5.

  3. Block on the condition variable releasing the mutex.

  4. Go to step 2.

  5. Remove the item from the queue.

  6. Release the mutex.

  7. Process the item we removed from the queue.

  8. Go to step 1.

You may want to prevent the queue from growing indefinitely though. It's always possible you might receive datagrams faster than you can process them and allowing the queue's memory usage to just keep growing is not a good idea.

Upvotes: 1

MOHAMED
MOHAMED

Reputation: 43528

Using thread is more simple because threads could see the memory of its paraent process. so it could access to variables and to memory, read them and change them.

Using process will not allow you to access in write directly to the parent process memory you have to use other ways to change variable and memory of parent process like shared memory (mmap)

Upvotes: 0

Related Questions