Ozzi wrote:
> Thomas Christian Chust wrote:
>
>> I think it would suffice for daemonize to wrap the call to the daemon's
>> main procedure in a dynamic-wind block and call the cleanup function
>> from the exit thunk. Unless the daemon procedure terminates itself with
>> a low-level _exit or by sen
On Wed, Oct 31, 2007 at 12:09:27PM +0100, felix winkelmann wrote:
> On 10/31/07, Peter Bex <[EMAIL PROTECTED]> wrote:
> >
> > Well, so be it. I'll add a note to 'extensions to the standard' and the
> > documentation of 'exit' because I'm sure there are more people out there
> > who are not aware o
On 10/31/07, Peter Bex <[EMAIL PROTECTED]> wrote:
>
> Well, so be it. I'll add a note to 'extensions to the standard' and the
> documentation of 'exit' because I'm sure there are more people out there
> who are not aware of this.
This has nothing to do with the standard. "exit" is not a standard
On Wed, Oct 31, 2007 at 11:23:59AM +0100, felix winkelmann wrote:
> > Why wouldn't it if you use dynamic-wind? The thunk is exited by
> > calling (exit), isn't it? So I would *expect* it to call the 'after'
> > part of the dynamic-wind. Just from reading the standard I would never
> > consider t
On 10/31/07, Peter Bex <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 31, 2007 at 10:24:44AM +0100, felix winkelmann wrote:
> > On 10/31/07, Peter Bex <[EMAIL PROTECTED]> wrote:
> > > >
> > > > The "exit" will not invoke any pending dynamic-wind thunks
> > >
> > > Why not? Shouldn't it? IMHO it violate
On Wed, Oct 31, 2007 at 10:24:44AM +0100, felix winkelmann wrote:
> On 10/31/07, Peter Bex <[EMAIL PROTECTED]> wrote:
> > >
> > > The "exit" will not invoke any pending dynamic-wind thunks
> >
> > Why not? Shouldn't it? IMHO it violates POLA not to do so.
>
> Because it might not be desired.
Wh
On 10/31/07, Peter Bex <[EMAIL PROTECTED]> wrote:
> >
> > The "exit" will not invoke any pending dynamic-wind thunks
>
> Why not? Shouldn't it? IMHO it violates POLA not to do so.
Because it might not be desired. It shouldn't. And I don't know who POLA
is, nor did I meeet her before.
cheers,
f
On Wed, Oct 31, 2007 at 07:44:19AM +0100, felix winkelmann wrote:
> On 10/31/07, Ozzi <[EMAIL PROTECTED]> wrote:
> >
> > Ok, I think I understand what you're getting it. Unfortunately I can't get
> > it to
> > work. You'll have to excuse the thrown-together quality of the code below,
> > but
> >
On 10/31/07, Ozzi <[EMAIL PROTECTED]> wrote:
>
> Ok, I think I understand what you're getting it. Unfortunately I can't get it
> to
> work. You'll have to excuse the thrown-together quality of the code below, but
> it demonstrates the problem I have. Perhaps I am just mis-using dynamic-wind,
> or
Thomas Christian Chust wrote:
> I think it would suffice for daemonize to wrap the call to the daemon's
> main procedure in a dynamic-wind block and call the cleanup function
> from the exit thunk. Unless the daemon procedure terminates itself with
> a low-level _exit or by sending itself a kill
Mark Fredrickson wrote:
>> I think it would suffice for daemonize to wrap the call to the daemon's
>> main procedure in a dynamic-wind block and call the cleanup function
>> from the exit thunk. Unless the daemon procedure terminates itself with
>> a low-level _exit or by sending itself a kill sig
> I think it would suffice for daemonize to wrap the call to the daemon's
> main procedure in a dynamic-wind block and call the cleanup function
> from the exit thunk. Unless the daemon procedure terminates itself with
> a low-level _exit or by sending itself a kill signal, the cleanup code
> shoul
Ozzi wrote:
> Thomas Christian Chust wrote:
>
>> I wonder why one would want to pass this cleanup argument to the daemon
>> procedure -- why should the spawned process simply perform cleanup once
>> the daemon procedure returns?
>
> The problem with that, as I see it, is that sometimes daemons d
Thomas Christian Chust wrote:
I wonder why one would want to pass this cleanup argument to the daemon
procedure -- why should the spawned process simply perform cleanup once
the daemon procedure returns?
The problem with that, as I see it, is that sometimes daemons don't get to
return normall
grok that. im trying to get chicken working in visual studio. this does not
rate amongst the 'fun' things i have done. yay work requiring ms os.
-elf
On Fri, 26 Oct 2007, Alex Queiroz wrote:
Hallo,
On 10/26/07, Elf <[EMAIL PROTECTED]> wrote:
heh, none of these are going to work everyw
Hallo,
On 10/26/07, Elf <[EMAIL PROTECTED]> wrote:
>
> heh, none of these are going to work everywhere. all posix extensions are
> custom. the only i/o procs in the standard are call-with-[input|output]file,
> with-[input|output]-to-file, current-[input|output]-port,
> [input|output]-file?,
> [
heh, none of these are going to work everywhere. all posix extensions are
custom. the only i/o procs in the standard are call-with-[input|output]file,
with-[input|output]-to-file, current-[input|output]-port, [input|output]-file?,
[open|close]-[input|output]-file, write, display, read, load,
On Fri, 26 Oct 2007, Thomas Christian Chust wrote:
Elf wrote:
um, why not just use (duplicate-fileno (portfileno )) ? [...]
Because not the file descriptor of a given port should be duplicated but
rather the file descriptor of a given port should be replaced by a
duplicate of another one.
Hallo,
On 10/26/07, Elf <[EMAIL PROTECTED]> wrote:
>
>
> (re: the daemon question, i would just use
> (foreign-lambda int "daemon" int int) ,
> but thats just me.)
>
A very nice solution... If it worked (everywhere).
Cheers,
--
-alex
http://www.ventonegro.org/
___
Elf wrote:
> um, why not just use (duplicate-fileno (portfileno )) ? [...]
Because not the file descriptor of a given port should be duplicated but
rather the file descriptor of a given port should be replaced by a
duplicate of another one.
Of course one could use (portfileno ...) instead of th
um, why not just use (duplicate-fileno (portfileno )) ? or if its
only stdin/stdout/stderr that youre worried about, calling
(current-[input|output|error]-port) with an argument should change the value.
the above three procs are parameters
(re: the daemon question, i would just use
Ozzi wrote:
> I am working on for creating unix daemons. Can anyone tell me how to
> redirect stdout and stderr? I want to redirect them to /dev/null by
> default.
Hello,
such an egg would indeed be a useful addition :-)
To redirect the standard file descriptors I would suggest to use the
same
I am working on for creating unix daemons. Can anyone tell me how to redirect
stdout and stderr? I want to redirect them to /dev/null by default.
I would also be interested in comments on my plans for the egg in general.
Presently, the interface is as follows:
daemonize is a function that tak
23 matches
Mail list logo