Multiprocess I/O

[James Kuyper]

He's not a bot.

From the syntax of his English language I'd say he Asian, probably
Chinese, without strong English language skills so his posts are short
and terse. He has background in hardware design, probably electronics
engineering and mathematics.

The poor connection between what people write and his responses make
that hard to believe. His unresponsiveness to my questions is also a
contributing factor. Even if he had no desire to answer them, a comment
to that effect would have gone a long way toward removing my suspicion
that he's actually a bot which is insufficiently sophisticated to even
understand my questions, much less answer them.

What I think he means to say is that while C isn't a multiprocessing
language, the problems of multiprocessing are addressable in C even if
it's outside the scope of the C standard. These multiprocessing issues
were addressed and solved in existing C-like HDLs.

That sounds perfectly reasonable, and completely irrelevant. Yes, those
issues could be addressed in the C standard, but the committee choose to
define them as being outside of the scope of that standard. As a result,
there is no "C" answer to the OP's question; in fact, C can be, and has
been, implemented on systems where the OP's question is meaningless
because there's never more than a single process running at the same time.

On systems where there is a meaningful answer to the OP's question, that
answer depends upon the standard, if any, which does describe how
multiple processes interact on the platform in question (which was never
specified), and is best determined by asking in a forum specializing in
that standard.

That's why I was repeatedly trying to prompt 88888 Dihedral to explain
why he thought his comments were relevant.

 

[James Kuyper]

On 13/03/14 12:47, James Kuyper wrote: ....

Whether "multi-process" is a hardware or OS issue depends on what you
mean by "process".

In the context of the C standard, "process" means whatever it's defined
to mean by that standard. The C standard uses "process" as a verb in
many contexts, which makes it hard to certain about such things, but I
don't believe it ever uses "process" as a noun. It therefore has no need
to define it, and that simple fact is, in itself, sufficient to
guarantee that the standard says nothing that's relevant to the OP's
question.

 

[88888 Dihedral]

If that's what he was saying, it's a poor way of making that point - if

88888 Dihedral is a bot, then 88888 Dihedral is still the name of that

bot (or at least, one of it's names).

Besides those non-senses, I am not
intereted in keeping conversations
with non-qualified untrained
developers.

Don't stray away from solving the
multi-process I/O problems which
were solved in spice and game engines long time ago by professionals.

 

[Kaz Kylheku]

You've lost me. I can't parse that in any way that makes sense - "it's
own posts are mostly incomprehensible" ?

Without addressing, why would the s command apply to the first line?

 

[Geoff]

Don't stray away from solving the
multi-process I/O problems which
were solved in spice and game engines long time ago by professionals.

They were solved but not by "pure C". The original question was "what
does the C standard and it's standard library do for I/O scheduling"
and the correct answer is "nothing", it's an OS question. Solution of
the I/O contention problem is outside the scope of the C standard.

 

[Geoff]

The poor connection between what people write and his responses make
that hard to believe. His unresponsiveness to my questions is also a
contributing factor. Even if he had no desire to answer them, a comment
to that effect would have gone a long way toward removing my suspicion
that he's actually a bot which is insufficiently sophisticated to even
understand my questions, much less answer them.

Are you now presenting yourself to be an expert in Goggle Translate
and Asian languages and you have used translation tools to hold
written correspondence with Chinese speakers? I have, and I can tell
you it's both tedious and inaccurate as I have verified Google
Translate translations with my wife who is a native speaker of Chinese
with degrees in Chinese history and literature. But they are getting
better.

He seems to be more of a sniper in the bushes in his posting technique
in this group and I believe I have seen him post follow ups that
related

That sounds perfectly reasonable, and completely irrelevant. Yes, those
issues could be addressed in the C standard, but the committee choose to
define them as being outside of the scope of that standard. As a result,
there is no "C" answer to the OP's question; in fact, C can be, and has
been, implemented on systems where the OP's question is meaningless
because there's never more than a single process running at the same time.

I'm not sure what you consider to be irrelevant. My guess is that you
consider C-like HDLs to be irrelevant and I would agree. But this is
consistent with my sniper theory WRT 88888 Dihedral. I also agree that
it is outside the scope of the standard as I explained in my reply to
the OP very much earlier in this topic and I was not advocating
anything of the kind for standard C.

 

[James Kuyper]

On Thu, 13 Mar 2014 10:34:15 -0400, James Kuyper


Are you now presenting yourself to be an expert in Goggle Translate
and Asian languages and you have used translation tools to hold
written correspondence with Chinese speakers?

I didn't actually mention it, but I've had a lot of experience the kinds
of miscommunications that can happen when dealing with Chinese speakers
in English. Many of my co-worker are and have been Chinese, and so is my
wife.

Something I've not seen much of is failing to notice that a question has
been asked, and as a result, failing to answer it. Chinese handles
questions quite differently than English; for instance, one way they can
ask questions is equivalent to "You want / don't want to have dinner?",
and another is equivalent to "You sold that coat to who?", both of which
would be odd constructs in English.

However, I can't remember ever having a native Chinese speaker fail to
recognize that a question has been asked. It's possible that 88888
Dihedral is not a bot, but if so, I suspect that his failure to answer
my questions was a deliberate choice, not the result of a translation
failure.

....

I'm not sure what you consider to be irrelevant.

In this context, anything that does not contribute to some way in either
answering the OP's question (which isn't possible, because he was
looking for a C answer), or explaining to the OP why no answer is
possible, and explaining what the OP should do about that fact.

The fact that answers to the question are possible, and that the C
standard could have been written to provide those answers, is
irrelevant, given the fact that it does not in fact do so.

 

[James Kuyper]

On 03/13/2014 01:52 PM, James Kuyper wrote:
....

in English. Many of my co-worker are and have been Chinese, and so is my

That came out wrong. I should have said "Many of my current and prior
co-workers have been Chinese".

 

[Geoff]

On 03/13/2014 01:52 PM, James Kuyper wrote:
...

That came out wrong. I should have said "Many of my current and prior
co-workers have been Chinese".

Then you know where I am coming from. I agree, 88888 is being
deliberately rude, as exemplified by his most recent statement:

"Besides those non-senses, I am not intereted [sic] in keeping
conversations with non-qualified untrained developers."

He's a sniper, sitting around waiting for targets of opportunity,
takes a shot and crawls back into his hiding place. Bots don't
necessarily have egos.

 

[David Brown]

Without addressing, why would the s command apply to the first line?

I assumed that the sed commands apply to all the quoted lines, although
I just gave the first as an example. It makes little sense:

its own posts are mostly incomprehensible, with all sorts of ideas
jumbled up. But I'm guessing Dihedral 88888 don't know much about
hardware description languages, so allow me to give Dihedral 88888 a
couple of points that might help Dihedral 88888 understand the
background for some of its own comments.



I assume you are trying to tell me you think I should have written that
Dihedral 88888 knows little about HDL's, rather than that James doesn't
know much about them. If that is what you want to say, then please say
it - being "smart" and "nerdy" with a sed script only works if it is
clear and accurate.


(As a side issue, it turns out that in this particular case you were
wrong - I did mean to address James, because I thought that he would
appreciate a few background pointers on Verilog and HDL's. I can't get
enough out of 88888's posts to tell what he might or might know about.)

 

[88888 Dihedral]

I assumed that the sed commands apply to all the quoted lines, although

I just gave the first as an example. It makes little sense:



its own posts are mostly incomprehensible, with all sorts of ideas

jumbled up. But I'm guessing Dihedral 88888 don't know much about

hardware description languages, so allow me to give Dihedral 88888 a

couple of points that might help Dihedral 88888 understand the

background for some of its own comments.







I assume you are trying to tell me you think I should have written that

Dihedral 88888 knows little about HDL's, rather than that James doesn't

know much about them. If that is what you want to say, then please say

it - being "smart" and "nerdy" with a sed script only works if it is

clear and accurate.





(As a side issue, it turns out that in this particular case you were

wrong - I did mean to address James, because I thought that he would

appreciate a few background pointers on Verilog and HDL's. I can't get

enough out of 88888's posts to tell >>what he might or might know about.)

Keep nonsensing stuffs in writing
and reading does not solve the problem
at all. Don't you get the messages?

 

[Seebs]

[trying to communicate with 88888 Dihedral]
If you think that describes me, I'm not going to bother proving you
wrong. But if talking with me bores you, that's only fair. Your
every response to any of my messages has been a non-sequitur, which
frustrates me at least as strongly as I bore you.

In another newsgroup (comp.lang.python) the regulars came to the
conclusion that "88888 Dihedral" is some kind of bot that posts
incoherent messages and thus simply ignore him/her/it(?).

My read would be that this is not much like a bot, but is very much like
fairly typical internet kookery.

-s

 

[Seebs]

Without addressing, why would the s command apply to the first line?

The most likely behaviors would be either (1) modify the first instance of
each in the entire block or (2) modify the first instance of each on any
given line. "Modify only most recent line" is not the behavior I usually
see when something's presented as a modifier to a block of text.

-s

 

[88888 Dihedral]

On 12.03.2014 22:16, James Kuyper wrote:

[trying to communicate with 88888 Dihedral]
If you think that describes me, I'm not going to bother proving you
wrong. But if talking with me bores you, that's only fair. Your
every response to any of my messages has been a non-sequitur, which
frustrates me at least as strongly as I bore you.

In another newsgroup (comp.lang.python) the regulars came to the

conclusion that "88888 Dihedral" is some kind of bot that posts

incoherent messages and thus simply ignore him/her/it(?).

My read would be that this is not much like a bot, but is very much like

fairly typical internet kookery.

OK, I can appreciate that. But humans
can laugh at jokes.

 

[CHIN Dihedral]

They were solved but not by "pure C". The original question was "what

does the C standard and it's standard library do for I/O scheduling"

and the correct answer is "nothing", it's an OS question. Solution of

the I/O contention problem is outside the scope of the C standard.

Since I worked on this kind of problems a few years ago in the VLSI
design, thus let's have fun in playing
with the CS experts who might not
know system C.

 

[Kaz Kylheku]

Since I worked on this kind of problems a few years ago in the VLSI
design

Like hell you did.

 

[Michael Angelo Ravera]

Hi,

In 'C', if two processes are doing their I/O then is there
any particular order adhered by the two ?

Suppose Process P1's I/O takes 5 minutes & Process P2's I/O takes
10 minutes, then does 'C' allow P1 to complete its I/O before
P2 even starts given that both start doing at the same time ?

This isn't really a C question but an OS question, but let me try to be helpful.

The whole point of having two separate processes in the first place is PRECISELY so that you *CAN'T* know the answer to your question. Processes that don't synchronize with each other aren't supposed to know or care about each other.

If the I/O for each processes were to be playing a song, you might end up with any of the following:
1) the entire first song plays and then the entire second song plays
2) the entire first song plays and second one starts but is suppressed until the first is finished and then plays whatever remaining time, if any, it has
3) the first song plays normally until the second song begins and then the first is suppressed while second song plays in its entirety. If the second song is sufficiently short, the time remaining on the first song completes.
4) the first song plays normally until the second one starts and then the higher (or lower or louder or softer or closest to A440) of the two notes at any time is played until one of them finishes and then we hear only the song with remaining time
5) the first song plays normally until the second one starts and then the sum (or some weird transform) of the two notes at any time is played until one of them finishes and then we hear only the song with remaining time
6) the first song plays normally until the second one starts and they play together until one of them finishes and then we hear only the song with remaining time
7) the first song plays normally until the second one starts and the two songs interleave until one of them finishes and then we hear only the song with remaining time
8) the first song plays normally until the second one starts and interrupts the first one and then the second song plays in its entirety and then the first song resumes.

All of these are possible ways to write a sound driver and you might find people who say "you always ought to do it whichever way". The OS could queue these things to the sound driver or prioritize them or present things in particular chunks.

Everything that I wrote about sounds could apply to a text screen, a video screen, a printer, a disk file, or a fountain controller.

But, as I said, the whole point of having processes is so that you can predict but not know for certain how the processes will interact unless they deliberately interact (signal, share memory, pipe, send interprocess messages) with each other.