Jon Gomez <jon.gomez.04@cnu.edu> wrote:
> > You can unset the bash option (or simply not set it), use disown, nohup,
> > whatever. In general, processes do NOT die when their parent dies!
> > That would be crazy.
>
> Okay, good point... But not entirely true, it seems:
>
> 27.5 Orphaned Process Groups
> ============================

Where is this from?

> When a controlling process terminates, its terminal becomes free and a
> new session can be established on it. (In fact, another user could log
> in on the terminal.) This could cause a problem if any processes from
> the old session are still trying to use that terminal.
>
> To prevent problems, process groups that continue running even after
> the session leader has terminated are marked as "orphaned process
> groups".

Just test. You'll find that processes launched from a shell are NOT
sent a HUP when their parent dies, if huponexitwhatever is not set.
I hope! So what you say cannot be true in that case.

> When a process group becomes an orphan, its processes are sent a
> `SIGHUP' signal. Ordinarily, this causes the processes to terminate.
> However, if a program ignores this signal or establishes a handler for
> it (*note Signal Handling:, it can continue running as in the orphan
> process group even after its controlling process terminates; but it
> still cannot access the terminal any more.
>
>
> libc info 0.10.

Oh - I must say I have never had an info file for libc! But anyway, you
can see the problem: libc is not emotionally involved. When a process
dies it dies, independently of whether it is compiled against libc or
not!

>
> >> > If the original poster has access to the Java source code, it could
> >> > probably be modified to do the same.
> >
> > Not necessary. Java will launch daemon processes! The java thread library
> > has special calls/options to do so.
>
> I hope you're not thinking of setDaemon().


As far as I recall I am. But I haven't looked for several years.

> It seems that its purpose is to
> designate threads that are to die if there are no longer any "user"
> threads,

You can designate user and daemon threads. Daemon threads are intended
to not be subject to certain restrictions. I believe you have misread.


> contrary to extending their lifespans. A java server might be an
> exception to this, but haven't tested with one.

??? This is ordinary java.

> > What first problem? And no, you do not so understand, because there is
> > no implication that parent/child will cause the child to die when the
> > parent does! That's crazy. There is a special setting in the bash
> > shell that will enable that, but it is not normal.
>
> Define normal? Using SIGHUP is a security feature.

Test and see.

> >> However, I'm not sure if it's possible to use a fork or something
> >> alike in Java. I doubt it since java is os independent.
> >
> > Nonsense. Java's process/thread methods cater specifically for all
> > this! Java is a parallel processing language.
>
> Yes, study that threading architecture!

??? Java has threads. In a "green thread" implementation of java, they
will be emulated in the support architecture. In a "native thread"
implementation, they will be translated to arch threads. The latter
are processes on linux.

> > What "concurrency problem"? It really sounds like you want to read a
> > book on java threads.
>
> Not if there is a desire for two distinct programs, even wherewithal

Especially if so. Java is a parallel language. See the threads class.

> dependencies. However, I can't see why the second (dependent) program
> can't run the first.

????


> Speaking of OS independent, there exists a native code interface, by which
> you can write C/etc., system code and use it in java.

Sure - why not. But it's silly. You can compile java.

> >> Ok I could run a loop until the first one has started. But isn't it
> >> possible to wait somehow until the program has started up...
>
> Waiting implies some kind of loop, possibly obscured at the kernel level.
>
> > Of course. That's normal. "Wait" on the other.
>
> Almost funny (Object.wait()), but not quite. Can't you be a little nicer?

??? Yes, as I recall, wait() is a method of the object class. What are
you trying to say?

Peter