Peter,

It looks like I should try to write more clearly. :-( Maybe I can do
better this time. (except I'm writing it in the middle of night, very
tired, so forgive sp/grammar errors)


Peter T. Breuer wrote:


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

I'm sure it's true. My question is how the shell interacts with the way
other parts of the system (kernel, system libraries = libc). My research
suggests that the shell's setting immunity to SIGHUP is part of a larger
context. I will do more studying (give me a few days), and get back to
you. If you want, you can look up the gnu libc manual online (easily
googled), and find what I was quoting under "Job Control".

Looking some more does state that in the general case a process is assigned
a new parent on parent death (usu. init)... but I think terminals are
different. I will have to find out.

> When a process
> dies it dies, independently of whether it is compiled against libc or
> not!

True.

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

Not only did I read it in the 1.4 sdk api and look up an alternative
reference, but I ran a sample program. Here is an improved version (set
RunAsDaemon true for daemon, false for normal thread.) The thread sends
output to a file it creates in /tmp/daemon-test continuously, so you should
be able to tail -f it:

import java.io.*;

public class daemon implements Runnable {
static boolean RunAsDaemon = false;


String fname = "/tmp/daemon-test";
String text = "teststuff\n";
FileWriter f;


//Starts up a new daemon
public static void main(String args[]) {
Thread t;
daemon d;

System.out.println("Starting new thread");
d = new daemon();
t = new Thread(d);

// Make that sucker a daemon thread!
if(RunAsDaemon) {
try {

t.setDaemon(true);
} catch (SecurityException se) {
System.out.println("Not allowed!");
} catch (IllegalThreadStateException itse) {
System.out.println("Hm... shouldn't happen ;-)");
}
}
t.start();

System.out.println("main() finished");
}

// Open a file for writing and write to it continuously
// we can use 'tail -f' to watch if anything is happening.
public void run() {
System.out.println("Thread has started.");

try {
f = new FileWriter(fname);
} catch(IOException ie) {
System.out.println("File can't be opened!");
}


while(true) {
try {
f.write(text);
f.flush();
Thread.sleep(1000);
} catch(InterruptedException ie) {
} catch(IOException ie) {
System.out.println("Error writing to file");
}
}


} //end of run()

} //end of class daemon


>> A java server might be an
>> exception to this, but haven't tested with one.
>
> ??? This is ordinary java.

There are versions of java that run as background system processes, for
example, on the Solaris computers at my school, and serve requests for
running java applications, rather than starting a new vm each time. Please
see the following reference:
http://java.sun.com/j2se/1.4.2/docs/guide/vm/index.html


>> Define normal? Using SIGHUP is a security feature.
>
> Test and see.

What I mean is, the goal of SIGHUP is to heap ensure that the terminal is
clean of dubious processes, isn't it?


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

I was agreeing with you. You're straight on.


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

Could be. I think creating separate programs goes beyond the idea of
separate processes, insofar as it could be a case where the first program
is highly self-defined but the second not so. I mean, we could design our
software in a way that is monolithic to the user, but I prefer applications
broken into pieces. So the question is for our friend to decide, because
he is the one writing the program(s). But I agree, considering that they
are init-scripts, and for limited use only, they probably would do better
as threads.


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

You're right it's silly. And fun. Heck, one day I want to write java in
bytecode. I've already practiced reading the class files in hex a little.
There's apparently a programming tool called SWIG which eases the task of
connecting all sorts of languages.


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

I apologize- I made an inappropriate assumption here. I thought you were
making fun of Fritz. To be honest, I worried about this after I sent my
message off.


Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --