Re: socket programming using MSG_WAITALL for receiving multicast ?packets

In article
<37559f82-5ef4-4fa8-bfea-39dd06dc5d39@f63g2000hsf.googlegroups.com>,
David Schwartz <davids@webmaster.com> wrote:

> On Mar 20, 4:48 pm, Rick Jones <rick.jon...@hp.com> wrote:
> 
>
> That's several orders of magnitude worse than what he's doing.
> Consider a typical packet of data received, how many system calls he
> needs, and how many system calls that needs.
>
> There is, also, one other huge difference. Posting larger reads
> doesn't change when your process is made ready-to-run. Whether you try
> to read one byte or one thousand, you will become ready-to-run at the
> same time. He is looking for a way to change when his process becomes
> ready-to-run -- he's looking to make it later. That wastes CPU time he
> could be using to process the packet(s) he has already received.

It sounded like some kind of audio processing application.  There's no
point in processing the packets faster than they can be played, you're
just going to get blocked on the output side.  If you don't need to
process packets as soon as they arrive, some savings could be achieved
if the recv's could be batched up.

However, I think the OP's worries are overblown.  While there have been
operating systems that had considerable overhead to switch between user
and kernel modes (comparable to switching between processes), I think
most modern Unixes use pretty efficient mechanisms.  Rather than having
completely separate user and kernel address maps, they use the same
address map and just flip some permission bits (so that when you're in
user mode you don't have access to the kernel portion of the addres
space).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***