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: Peter Olcott on 8 Apr 2010 17:05

"Scott Lurndal" <scott(a)slp53.sl.home> wrote in message
news:bhrvn.76527$K31.52640(a)news.usenetserver.com...
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>
>>I just checked the third party provider provides UPS. Most
>>experts seem to say not to worry about the disk drive's
>>onboard cache if UPS is available.
>
> I would argue this. A reboot may blow the drive cache
> away before
> it is synchronized to disk. I suspect you're confusing
> with drive
> write caches used in RAID subsystems (e.g. DG/EMC Aviion,
> EMC symmetry),
> where there is additional control hardware to ensure that
> the
> cache is flushed when the transition from mains to
> batteries occurs.
>
> Most server quality drives do not enable write caching.
> If you're
> using an inexpensive SATA desktop drive, you can turn
> write caching
> off with 'hdparm(1)'.
>
> scott

The service provider could not easily tell me the type of
drive, I suspect it is SCSI.
They did say that I could turn off write caching. It looks
like I may have to err on this safe side.

From: Ersek, Laszlo on 8 Apr 2010 17:44

On Thu, 8 Apr 2010, David Schwartz wrote:

> 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?

From the rationale I've linked to earlier,

----v----
As explained, there is no suitable solution for functionality which
requires non-atomic operations to be protected through mutexes and locks.
This is why the POSIX.1 standard since the 1996 release requires that the
child process after fork() in a multi-threaded process only calls
async-signal-safe interfaces.
----^----

Now on to my own (botched) ideas:

The parent may rely on SIGCHLD, which is generated for the process. The
signal might be delivered to a "shadow thread".

>> 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.

See alarm(), followed by a connect(). The SIGALRM is generated for the
process, which might be delivered to a "shadow thread".

Another example:

static volatile sig_atomic_t caught_int,
caught_term;

static void
sigs_handle(int sig)
{
*(SIGINT == sig ? &caught_int : &caught_term) = 1;
}

static void
sigs_inst(void)
{
struct sigaction sa;
int ret;

sa.sa_handler = &sigs_handle;

ret = sigemptyset(&sa.sa_mask);
assert(0 == ret);

sa.sa_flags = 0; /* note, SA_RESTART is absent */

ret = sigaction(SIGINT, &sa, 0);
assert(0 == ret);

ret = sigaction(SIGTERM, &sa, 0);
assert(0 == ret);
}

(No comments on style now, please; we're talking about correct
single-threaded processes, not *nice* ones.)

Suppose the program is blocked in a read() call and expects it to return
with -1/EINTR (suppose the two signals mentioned above are not blocked at
all and EINTR is handled everywhere), after which the program does some
cleanup. If another process generates SIGTERM for this process (that is,
asynchronously), and the signal is delivered to a "shadow thread", that
thread will execute the handler, and the "main thread" won't return from
read() with -1/EINTR.

Suppose now that yet another process sends a SIGINT similarly, which is
this time delivered to the "correct thread". If the main thread, woken up
from read(), checks "caught_term" *first*, the behavior is undefined,
because that object was modified by a different thread with (possibly or
probably) no intervening call to any routine that would synchronize memory
state (ie. the listed pthread_*() functions). "volatile" is absolutely no
help here.

"Shadow threads" might want to call pthread_sigmask() as soon as they are
created to block all signals. There seems to be a race, though. Of course,
the C library may make use of a kernel facility that takes a signal mask
as a thread attribute before spawning the thread. I guess a *C* library
can do whatever it wants, since everything goes through it in a portable
program.

For the likely case of all my examples being epic failures, please note
that the inability to provide any counterexample for conjecture C doesn't
render conjecture C theorem T, that is, it doesn't prove it.

I'd greatly appreciate any followup, provided anything in this jumble
merits such.

Thanks,
lacos

From: Ian Collins on 8 Apr 2010 17:47

On 04/ 9/10 01:34 AM, Peter Olcott wrote:\
>
> I have to top post whenever I am replying to someone that
> some how turns quoting off, or there would be no way to tell
> who is saying what.

No, you don't. As I told you a week or so ago, you have to fix your
client. It is broken. The fix is well known (well there are two, the
other is to use a better client, especially on a Unix group!).

--
Ian Collins

From: Chris Friesen on 8 Apr 2010 18:56

On 04/08/2010 10:47 AM, David Schwartz wrote:

> 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 think it depends on your definition of threads.

I suspect you could arrange things so that a "single threaded" app
actually has multiple tasks at the OS level but from the perspective of
the app itself it only has a single thread.

As long as the second task doesn't use any of the APIs that are defined
to not be thread-safe (gethostbyname(), gethostbyaddr(), etc.), doesn't
interfere with signals, doesn't interfere with fork(), etc. I suspect
there wouldn't be a problem.

Chris

From: Peter Olcott on 8 Apr 2010 19:04

"Ian Collins" <ian-news(a)hotmail.com> wrote in message
news:82717jFp8jU4(a)mid.individual.net...
> On 04/ 9/10 01:34 AM, Peter Olcott wrote:\
>>
>> I have to top post whenever I am replying to someone that
>> some how turns quoting off, or there would be no way to
>> tell
>> who is saying what.
>
> No, you don't. As I told you a week or so ago, you have
> to fix your client. It is broken. The fix is well known
> (well there are two, the other is to use a better client,
> especially on a Unix group!).
>
> --
> Ian Collins

I don't have time to mess with this.