And another thing about discussions in KOM in general: it is often the case that the debate or discussion itself runs amok just because some, possibly several, person(s) start talking about philosophy, operating systems behaviour or other somewhat unrelated topics rather than being in disagreement about relevant facts.
Thanks for the tip :)
I'm sure nobody would object about a Process.daemonize() call if you or someone else who wanted it implemented it and tested it to work on systems where this is possible, and disabled and documented this added dependency on systems where it does not work. From what I have heard, implementing a Process.daemonize call would require a syscall giving an inverted fork(1) (to move along all threads), on systems with threads, or be easy on systems without threads.
I would be glad to implement it, but the discussion never reached the point beyond shuffling arguments back and forth about whether it makes or doesn't make sense. I'm all for implementing things but the impression I'm getting sometimes is that of reluctance to add some stuff to Pike because it can hypothetically hurt somebody or lead some poor programmer astray generating bad karma for Pike (which POV, no offence intended, is a complete bullshit IMHO). From now on I will try to implement something and only then come asking whether it is ok to include it in pike :)
Arguing that someone else should write it will almost certainly fail,
I'm far from asking anybody to implement my ideas, and that wasn't the objective of the discussion - I wanted to know the opinion of people, because it doesn't make much sense to implement something which seems good to me while in reality it might be a completely insane idea.
There has not yet been loud vetos against a daemonize call, but Marcus will not implement it, since he is fully satisfied with having the setsid (IIRC) hack for the same purpose in Process.create_process. The
I couldn't care less, frankly :) All I (and some other people) want is some features _we_ might prefero for whatever perverted reasons we might have :) And I can assure you that when/if I implement some code, I will take every measure not to bother anybody else with it and make it as portable as I can given the resources I have at hand.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 13:25: Subject: Process.daemonize()
And another thing about discussions in KOM in general: it is often the case that the debate or discussion itself runs amok just because some, possibly several, person(s) start talking about philosophy, operating systems behaviour or other somewhat unrelated topics rather than being in disagreement about relevant facts.
I'm sure nobody would object about a Process.daemonize() call if you or someone else who wanted it implemented it and tested it to work on systems where this is possible, and disabled and documented this added dependency on systems where it does not work. From what I have heard, implementing a Process.daemonize call would require a syscall giving an inverted fork(1) (to move along all threads), on systems with threads, or be easy on systems without threads.
Arguing that someone else should write it will almost certainly fail, implementing it on one's own will almost certainly succeed; doers decide, except for the cases where there are loud vetos. Of course, doers who show clear signs of disrespecting portability or other important issues; typically by not disabling functions on systems where they fail, failing to document such dependencies or naming the methods in a manner suggesting universal portability.
There has not yet been loud vetos against a daemonize call, but Marcus will not implement it, since he is fully satisfied with having the setsid (IIRC) hack for the same purpose in Process.create_process. The fact a daemonize call like this could be made in two different ways from the Pike level is not something that unlikely to irritate anyone.
/ Johan Sundström (risplockare)