Do named pipes have disk I/O ?? [Unix Programming]

Prev: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
Next: Why can't I catch a SIGBUS on my Mac (when strlen(NULL) is used)?

From: Rainer Weikusat on 8 Apr 2010 12:28

David Schwartz <davids(a)webmaster.com> writes:
> On Apr 8, 4:40�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>
>> [T]he C library must not silently turn a single-threaded process into a
>> multi-threaded one.
>
> Why not?

I already wrote this: Some UNIX(*) interface have different semantics
for single-threaded and multi-threaded processes, the most prominent
one being fork. Another would be sigprocmask. Signal handling is also
different. Actually, I didn't write the sentence above at all, but
wrote 'Because of ..., the C library ...'.

> Or, to put it another way, why must a platform even have any
> notion of a 'single-threaded process'?

I didn't claim that a platform must have a notion of a single-threaded
process, much in the same way as one of the older UNIX(*)
specifications didn't explicitly require multiprogramming support:
There is nothing which stops people from creating 'Deathstation
5000'-implementations just because these are by-and-large useless.

From: David Schwartz on 8 Apr 2010 12:47

On Apr 8, 9:28 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
> David Schwartz <dav...(a)webmaster.com> writes:
> > On Apr 8, 4:40 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>
> >> [T]he C library must not silently turn a single-threaded process into a
> >> multi-threaded one.
>
> > Why not?
>
> I already wrote this: Some UNIX(*) interface have different semantics
> for single-threaded and multi-threaded processes, the most prominent
> one being fork.

So what? Can you cite a single example where these semantics require a
difference that would be visible to an application that was designed
to be single-threaded?

> Another would be sigprocmask. Signal handling is also
> different. Actually, I didn't write the sentence above at all, but
> wrote 'Because of ..., the C library ...'.

The differences in signal handling would also be invisible to a
process designed to be single-threaded.

DS

From: Peter Olcott on 8 Apr 2010 12:50

OK then that is now more clear. It looks like my existing
design has to be modified so that a single process performs
all the operations upon the transaction log file.

(1) Exactly how reliable are Named Pipes?

(2) Is there a completely certain way that a write to a file
can be flushed to the disk that encompasses every possible
memory buffer, including the hard drives onboard cache? I
want to be able to yank the power cord at any moment and not
get corrupted data other than the most recent single
transaction.

"David Schwartz" <davids(a)webmaster.com> wrote in message
news:1eff02dd-15a0-4edb-ab5c-3557e0652038(a)8g2000yqz.googlegroups.com...
On Apr 7, 6:42 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com>
wrote:

> Documentation indicates that they are atomic.

But, again, you are confusing two different notions of
atomicity. They
are "atomic" in the sense that an intervening operation on
the same
file descriptor cannot cause the read or write to take place
at a
different offset. So you can't just implement 'pread' as a
seek
followed by a read.

But they are not atomic against operations on other
descriptors that
reference the same file. Nor is the read or write part of
the
operation itself atomic against the file.

They are only atomic in the sense that the seek is 'glued'
to the read/
write operation. In fact, the standards never define these
operations
as atomic in any sense and simply say that they don't
involve the file
position.

"The pread() function performs the same action as read(),
except that
it reads from a given position in the file without changing
the file
pointer." "The pwrite() function performs the same action as
write(),
except that it writes into a given position without changing
the file
pointer." (And 'write' is explicitly described as not
atomic.)

DS

From: Peter Olcott on 8 Apr 2010 12:52

I do remember that many of the STL library functions are
called thread safe. I am guessing that reentrancy may be the
issue here.

"David Schwartz" <davids(a)webmaster.com> wrote in message
news:5e25ecc5-a194-4c7b-bfc0-4124b2a589d2(a)q15g2000yqj.googlegroups.com...
On Apr 8, 4:40 am, Rainer Weikusat <rweiku...(a)mssgmbh.com>
wrote:

> [T]he C library must not silently turn a single-threaded
> process into a
> multi-threaded one.

Why not? Or, to put it another way, why must a platform even
have any
notion of a 'single-threaded process'?

DS

From: Rainer Weikusat on 8 Apr 2010 12:56

David Schwartz <davids(a)webmaster.com> writes:
> On Apr 8, 9:28�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>> David Schwartz <dav...(a)webmaster.com> writes:
>> > On Apr 8, 4:40�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>>
>> >> [T]he C library must not silently turn a single-threaded process into a
>> >> multi-threaded one.
>>
>> > Why not?
>>
>> I already wrote this: Some UNIX(*) interface have different semantics
>> for single-threaded and multi-threaded processes, the most prominent
>> one being fork.
>
> So what? Can you cite a single example where these semantics require a
> difference that would be visible to an application that was designed
> to be single-threaded?

I have no idea what you're up to.