Re: how to tell when a process is blocked in write()

On Tue, 03 Mar 2009 11:20:18 +0100 Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
| Phil Carmody <thefatphil_demunged@xxxxxxxxxxx> writes:
|> David Schwartz <davids@xxxxxxxxxxxxx> writes:
|>> On Mar 1, 9:05?am, phil-news-nos...@xxxxxxxx wrote:
|>>
|>>> What I am trying to accomplish is to have 2 child processes write to the same
|>>> descriptor inherited from the parent that opened it, in alternating succession
|>>> in an overlapped way. ?That is, as soon as one child is blocked in its write()
|>>> call, the parent will detect that and signal the other child to proceed to do
|>>> its call to write(). ?As soon as the second is blocked in write(), the parent
|>>> detects that and signals the first child, which would get the signal after the
|>>> write() call returns if it was still blocked when the signal is sent. ?In case
|>>> the parent is delayed in detecting the children being blocked, each child will
|>>> also signal tha parent when write() returns as a fallback in case detection
|>>> was slow (system too busy, for example).
|>>
|>> What's wrong with the normal ways to do this? Why do you need to
|>> invent some strange new way? And why do you think the 'write'
|>> operations will block? (Typically 'write' does not block.)
|>
|> What a strange thing to say. write blocks whenever it needs to
|> (and is permitted to).
|
| This depends on type of descriptor supposed to be written to. A write
| to a 'disk file' will only wait when a new page of memory would be
| needed by it and there isn't one until something else has been paged
| out.

If O_DIRECT and O_SYNC are used, it will wait also for the I/O to be complete.
It seems to do that also when only O_DIRECT is used, although by terminology,
that implies it only needs to wait until the I/O has been STARTED on the disk.
These are waits of "significant" time frame (compared to the time needed to
just copy a buffer into cache). These are the kind of wait times where waiting
does have an impact. Because this kind of I/O is is not cached, it impacts the
disk performance because it requires a full round trip back to the process to
start the next I/O. That can, for many devices, create a slowdown in excess of
the round trip time percentage.

Note that my original question was very specific and to the point. Answering
it did not need to know why I wanted to do this. If there is a way to do what
I asked for, someone could say there is, and maybe ever say how. If someone
does not know one way or the other, I don't see any value in them offering any
advice. If someone knows it is definitely not possible, then that answer is
also informative (even if disappointing). We have to get into why I want to
do this only because other people want to expand on the question or alter it
in some way. It is those expansions/alternations by others that then need more
info, such as the fact that I'll be doing direct and/or sync I/O. I do provide
that information to keep things going, especially when assumptions are made and
are made wrong (which can happen when questions get changed to ones where it
does matter).

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.

Relevant Pages

  • Re: using fork and wait reliably w/signals
    ... > I don't know what the book says about signals. ... you should wait for the child. ... > the parent process will exit soon anyway, ... If the system is not POSIX compliant, then you can ignore the SIGCHLD ...
    (comp.os.linux.development.system)
  • Re: using fork and wait reliably w/signals
    ... > a large buffer while the parent ... I don't know what the book says about signals. ... Must I wait on the child at some point knowing it ... In fact I think a SIGCHLD ...
    (comp.os.linux.development.system)
  • Re: using fork and wait reliably w/signals
    ... > a large buffer while the parent ... Signals are unreliable if you have two instances of the signal ... the signal handler you would set an atomic flag. ... *should* be a child ready to reap. ...
    (comp.os.linux.development.system)
  • Re: Executing 2 processes "fork()" alternatively
    ... I want the parent and the child to be executed alternatively. ... One of them is using signals, but they need to be used with great ... The first pipe ...
    (comp.unix.programmer)
  • Re: how to tell when a process is blocked in write()
    ... as soon as one child is blocked in its write ... |>> |> detects that and signals the first child, which would get the signal after the ... |>> Show me a case when writeto a disk or disk file does NOT block. ... Disk I/O is not. ...
    (comp.os.linux.development.system)