fork()

[CBFalconer]

http://www.opengroup.org/onlinepubs/009695399/functions/vfork.html
"The vfork() function differs from fork() only in that the child
process can share code and data with the calling process (parent
process)."

now if vfork() is different because it can share, and that is the
only difference, i think it's pretty clear that fork() cannot share.

Why is this off-topic thread continuing on c.l.c? Please find an
appropriate newsgroup. This is not it.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Walter Roberson]

http://www.opengroup.org/onlinepubs/009695399/functions/vfork.html
"The vfork() function differs from fork() only in that the child
process can share code and data with the calling process (parent
process)."

now if vfork() is different because it can share, and that is the only
difference, i think it's pretty clear that fork() cannot share.

vfork() is not part of POSIX.1 (IEEE 1003.1-1990), so if one is
working with C + POSIX.1 then the question still arises.

 

[Walter Roberson]

Why is this off-topic thread continuing on c.l.c? Please find an
appropriate newsgroup. This is not it.

This -is- the appropriate newsgroup.

I am upholding the comp.lang.c position, i.e., that that which is not
nailed down is not to be counted on, and that one must take the appropriate
measures in C to reduce the exposure to problems.

Others are attempting to impute behaviour to C based upon non-C
materials, but I happen to have a copy of the those materials and
demonstrated that those materials are not sufficient to specify the
effects upon C.

So this really is a comp.lang.c discussion, about the meaning and
uses of volatile.

 

[Default User]

Walter Roberson wrote:

vfork() is not part of POSIX.1 (IEEE 1003.1-1990), so if one is
working with C + POSIX.1 then the question still arises.

Please refrain from these OT posts. If you wish to continue, take it to
an appropriate newsgroup.


Brian

 

[Walter Roberson]

Walter Roberson wrote:

Please refrain from these OT posts. If you wish to continue, take it to
an appropriate newsgroup.

For the point I am making, this -is- the appropriate newsgroup.

I said, "This program attempts to use side effects mechanisms that
are outside of the control of the C implementation, and therefore
in accordance with the C standard, it needs 'volatile'." Others said
"No, this routine that is outside of the scope of C is certain not to
violate the C standards, so 'volatile' is not needed." I then had to
show that their certainty on that point was misplaced (at least in
theory).

I am, in other words, upholding the standard line in this newsgroup
that that which is not specified by C is to be considered unknown
and to be protected against as far as is possible within the C language.
If such a point is off-topic in this newsgroup, then a great deal of
the discussion in this newsgroup is also off-topic.

 

[Default User]

Walter Roberson wrote:

I am, in other words, upholding the standard line in this newsgroup
that that which is not specified by C is to be considered unknown
and to be protected against as far as is possible within the C
language. If such a point is off-topic in this newsgroup, then a
great deal of the discussion in this newsgroup is also off-topic.

This is pure nonsense. You've been discussing far more than that and
you know it. The proper place for ANY discussion of fork() is in
comp.unix.programmer.




Brian

 

[Walter Roberson]

Walter Roberson wrote:

This is pure nonsense. You've been discussing far more than that and
you know it.

Oddly enough, I don't "know it". I referred to other standards
only in the service of the point about C.

The proper place for ANY discussion of fork() is in
comp.unix.programmer.

And when someone asks in comp.sys.sgi.* about the details of
fork() in the SGI IRIX operating system, I should tell them that,
"Sure, that information is IRIX version specific, but you'll
have to go over to comp.unix.programmer because ..." ? You'll
have to help me out here, as I seem to be somewhat stuck on
the "because" part of that statement.

Your statement is particularily puzzling as the discussion
that you considered off-topic related to POSIX.1-1990's fork().
POSIX is the Portable Operating System Interface, and as such
encompasses more than Unix (and not all Unix are POSIX.) You are
proposing that users of non-Unix POSIX.1 compliant systems should
be relying on comp.unix.programmer for information about fork() ??


In other words, the "proper place" for the discussion of fork()
depends upon the context. For the context of the point I was
making, comp.lang.c was the proper newsgroup.

 

[Default User]

Walter Roberson wrote:

In other words, the "proper place" for the discussion of fork()
depends upon the context. For the context of the point I was
making, comp.lang.c was the proper newsgroup.

No, it wasn't. You made numerous off-topic statements.



Brian