// Welcome to the list! And here begins the nitpicking...
*groan* :)
// tail does what it does as it cannot assume anything about the source of the
generated file - can be logging process or some app or even a special device file.
Yes, the suggestion for hooking up with a pty was assuming that one has
control over the writing process, eg. syslogd, my_prog.c, UML.
// Now, an interesting question is that is this more efficient, i.e. reading/writing
to/from named pipe/pty rather than fstat'ing the file - don't both of them incur the
same penalty in terms of system calls?
Yes, they do, and they'd be more or less the same. It's only that one usually
makes the assumption that wakeup operations in kernel space, based on
wait_queues/sems/interrupts are more efficient than delegating the
responsibility for this sort of thing to a user space process by setting
up a timer, being woken up in userspace, making a system call and going
back to sleep.
For instance, if you take the host file system that User mode linux uses,
it makes it possible for kernel space code - drivers, etc. to register
for callbacks which are supported asynchronously by the file-system itself.
In effect, the whole loop is avoided, since the wakeup operation once again
is in teh kernel.
Here, user space applications know nothing about this capability of the UBD
file system, so a decision on whether to employ method (1) or method (2)
is just not on. You use method (2) and leave it to the kernel. There's no
reason we shouldn't assume teh same for the tty drivers to be able to
deal with other file systems in a similar, more efficient way than
processes in user-space can.
Also, when you're bludgening from userspace, you're forcing the operating
system to keep your executable pages (and god knows what with read-ahead)
in memory instead of swapping them out like any well-behaved system with
32Mb RAM should :) Especially if it's going to wake up and start being
useful again 6 months later when someone uses the CDwriter again (or
something). The async tty-reader would score on this, since there's no
activity in the program after a poll system call, ro indefinite sleep and
there's no activity in the kernel either since the wakeup operation is
invoked in the event of a write to the pty.
// You say that fstat would have to access the disk? This is something that I am not
sure about - when does Linux serialize changed filesyste info to disk? Are there
chances that when I do two consecutive fstat's "quickly" I might get data from in
memory?
fstats never read from disk. AFAIK, the generic buffer cache/ inode cache are
responsible this. i.e., values come out of cache and not the disk and
the cache is modified when the inode written to.
// What about the pty device? What if that memory gets swapped to disk?
ok. I don't think I understood your question right. lemme know if I've got
you all wrong--
in the case of the pty device, we're sleeping (interruptably) in kernel
space on a wait queue (tty_struct tty->read_wait). As long as a pty
device doesn't have any available data (i.e., the process writing to it
hasn't given any for a while), read_wait stays asleep. When the process
writes to a pty device, the pty driver hands over control to the line
discipline, which wakes up read_wait. The inference being that ALL
processes that wait for tty-input/output are put on the hook in the
line-discipline in a way that puts everything to rest...
So the processes aren't involved AT ALL in the wake=up
operations, which is how it should be since even here, wakeups can be
invoked by things like a call on fflush on the pty device, which again
the reading process knows nothing about and are better handled in kernel
space.
// What can we say about the chances for the above two incidents to happen
statistically.
disk accesses should happen everytime the inode buffers are flushed and will
depend on writes and not fstats.
the second (pty process memory being swapped out) is irrelevant since
again, the user space processes are not involved in the waking up
operations.
Sapan
// Regards,
// -Varun
/
================================================
To subscribe, send email to [EMAIL PROTECTED] with subscribe in subject header
To unsubscribe, send email to [EMAIL PROTECTED] with unsubscribe in subject header
Archives are available at http://www.mail-archive.com/ilugd%40wpaa.org
=================================================
