William Light wrote:
> I shied away from pipes initially because I figured that staying in
> user-space would let me keep tighter control on how quickly things
> execute.
User-space code can be swapped out (unless you have mlocked it). So
_replacing_ user-space code with some kernel code that already does the
same thing cannot make things worse.
> I've been following the JACK recommendation of avoiding "all I/O
> functions (disk, TTY, network)" as strictly as possible
That kind of I/O goes to real devices, which might have all sorts of
unpredictable delays.
In the case of an eventfd (or a pipe that is not connected to another
program), your program controls all aspects of the object, so you know
when it could block. Furthermore, operations will not block if you have
enabled non-blocking mode.
> I'm avoiding blocking, of course, but I'm also worried about the
> potential scheduling implications of jumping into kernel-mode and back
System calls executed from your process get accounted to your process,
just like user-space code. Interrupts can interrupt both kernel- and
user-space code.
Scheduling happens only when your time slice runs out (which can happen
in both user space and kernel space), or when you make a system call
that actually blocks.
Regards,
Clemens
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Sep 24 20:15:01 2014
This archive was generated by hypermail 2.1.8 : Wed Sep 24 2014 - 20:15:02 EEST