On Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > On 06-12-2011 12:38, Andreas Oberritter wrote: >> >> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote: >>> >>> O_NONBLOCK >>> When opening a FIFO with O_RDONLY or O_WRONLY set: >> >> ^^^^ This does not apply. >> >> [...] >> >>> When opening a block special or character special file that supports >>> non-blocking opens: >>> >>> If O_NONBLOCK is set, the open() function shall return without >>> blocking for the device to be ready or available. Subsequent behavior of >>> the device is device-specific. >> >> >> This is the important part: >> - It specifies the behaviour of open(), not ioctl(). I don't see a >> reason why open should block with vtunerc. >> - Read again: "Subsequent behavior of the device is device-specific." >> >>> If O_NONBLOCK is clear, the open() function shall block the >>> calling thread until the device is ready or available before returning. >>> >>> Otherwise, the behavior of O_NONBLOCK is unspecified. >>> >>> Basically, syscall should not block waiting for some data to be read (or >>> written). >> >> >> That's because open() does not read or write. >> >>> The ioctl definition defines [EAGAIN] error code, if, for any reason, an >>> ioctl would block. >> >> >> Fine. >> >>> Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for >>> example >>> read_snr[1], it calls wait_event_interruptible()[2], even if the >>> application opens >>> it with O_NONBLOCK flag. So, it is likely that non-blocking-mode >>> applications >>> will break. >> >> >> Of course, read operations must wait until the value read is available >> or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c >> transfer, an usb transfer or a network transfer doesn't make a >> difference. Every transfer takes a nonzero amount of time. > > > Yes, posix is not 100% clear about what "non block" means for ioctl's, but > waiting for an event is clearly a block condition. This is different than > doing something like mdelay() (or even mleep()) in order to wait for an > specific amount of time for an operation to complete. > > A vtunerc => daemon => network transfer =>daemon => vtunerc is a block > condition, > as the network may return in a few ms or may not return and a long > timeout at the daemon would give an error. Also, as the daemon may be > swapped > to disk (as the daemon runs on userspace), this may even involve other > blocking operations at the block layer. > > >> As Honza already demonstrated, in a typical LAN setup, this takes only >> few milliseconds, which with fast devices may even be faster than some >> slow local devices using many delays in their driver code. >> >> If an application breaks because of that, then it's a bug in the >> application which may as well be triggered by a local driver and thus >> needs to be fixed anyway. > > > It is not a bug in the application. It requested a non-block mode. The > driver > is working in block mode instead. It is a driver's bug. > > >>>> Mauro, if the network is broken, any application using the network will >>>> break. No specially designed protocol will fix that. >>> >>> >>> A high delay network (even a congested one) is not broken, if it can >>> still provide the throughput required by the application, and a >>> latency/QoS >>> that would fit. >> >> >> Then neither vtunerc nor any other application will break. Fine. >> >>>> If you want to enforce strict maximum latencies, you can do that in the >>>> userspace daemon using the vtunerc interface. It has all imaginable >>>> possibilities to control data flow over the network and to return errors >>>> to vtunerc. >>> >>> >>> Yes, you can do anything you want at the userspace daemon, but the >>> non-userspace daemon aware applications will know nothing about it, and >>> this is the flaw on this design: Applications can't negotiate what >>> network >>> parameters are ok or not for its usecase. >> >> >> How do you negotiate network parameters with your ISP and all involved >> parties on the internet on the way from your DSL line to some other >> peer? Let me answer it: You don't. > > > TCP flow control mechanisms, RSVP, MPLS, IP QoS flags, ICMP messages, etc. > You would need a Data Link Protocol, which would be PPP of some form http://en.wikipedia.org/wiki/Point-to-Point_Protocol I don't think, you have much to negotiate there. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
