Re: [rust-dev] Syntax sugar: Vec Rc RefCell Box Foo -> Vec>>>

[Nathan Typanski]

I ran stats on the type parameters on Rust's master branch.

(I was dumb and only sent this to Ben Striegel last time. My fault for
not knowing how to use an email client.)

On 06/30, Benjamin Striegel wrote:
> Whether or not we want something like this, I'd be fascinated if someone
> managed to gather stats on how many types take only a single type parameter.

I had to do part of this by hand (thanks to false positives and it
being cumbersome to script for lifetime parameters) but I ran

ag "pub.*struct.*<.*(?" > typed

in the rustc directory, did my best to weed out false positives, and
then counted by crate both the total and the number with only one
parameter.

So these numbers could be off by a bit - it's possible to write
structs that the regex above won't match, and it's possible that
somewhere I made a mistake counting things, but this should give a
nice rough idea.

- 160/191 (84%) parameterized structs in the "standard crates" take
only one type parameter.
- 40/50 in libcore
- 9/10 in librand
- 5/5 in liballoc
- 1/1 in debug
- 5/5 in librustrt
- 1/1 in libtest
- 2/2 in libterm
- 23/24 in libsync
- 3/3 in libserialize
- 19/28 in libstd
- 8/8 in libsyntax
- 27/34 in libcollections
- 11/14 in librustc
- 2/2 in libgreen
- 1/1 in libnative
- 1/1 in libarena
- 2/2 in libnum

For traits:

- 52/74 (70%) of parameterized traits take one type parameter.
- 23/37 in libcore
- 1/1 in librustrt
- 1/3 in libgraphviz
- 4/4 in librand
- 1/1 in libterm
- 4/6 in libserialize
- 11/13 in libcollections
- 2/3 in librustc
- 2/3 in libstd
- 1/1 in librustdoc
- 1/1 in librustuv
- 1/1 in libsyntax

Nathan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Steven Fackler]

There's a fix for make install waiting on bors right now:
https://github.com/rust-lang/rust/pull/15550

Steven Fackler


On Wed, Jul 9, 2014 at 1:11 PM, Ben Gamari  wrote:

> Brian Anderson  writes:
>
> > Hi.
> >
> > Very soon now the way rustc links crates dynamically is going to
> > change[1], and it will impact the way you work with Rust in some
> > important cases. The TL;DR is that rustc will no longer encode RPATH
> > information in the binaries it produces, so the dynamic linker will be
> > less likely to find the dynamic library (.so, .dylib) dependencies; in
> > some scenarios people will need to use LD_LIBRARY_PATH or rely on
> > higher-level tooling to arrange for libraries to be discovered by the
> > dynamic linker at runtime.
> >
> Perhaps I'm missing something obvious here, but this broke `make
> install` in the rustc tree for me. The cause appears to be that `make
> install` tries to verify that it can run the new `rustc` binary in
> place, which expectedly fails due to missing libraries,
>
> /opt/exp/rust $ make install
> ...
> install: verifying platform can run binaries
> /opt/exp/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc:
> error while loading shared libraries: libnative-4e7c5e5c.so: cannot open
> shared object file: No such file or directory
> install: error: can't execute rustc binary on this platform
> make: *** [install] Error 1
>
> Surely I don't need to mangle LD_LIBRARY_PATH just to run `make
> install`?
>
> Cheers,
>
> - Ben
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Ben Gamari]

Brian Anderson  writes:

> Hi.
>
> Very soon now the way rustc links crates dynamically is going to 
> change[1], and it will impact the way you work with Rust in some 
> important cases. The TL;DR is that rustc will no longer encode RPATH 
> information in the binaries it produces, so the dynamic linker will be 
> less likely to find the dynamic library (.so, .dylib) dependencies; in 
> some scenarios people will need to use LD_LIBRARY_PATH or rely on 
> higher-level tooling to arrange for libraries to be discovered by the 
> dynamic linker at runtime.
>
Perhaps I'm missing something obvious here, but this broke `make
install` in the rustc tree for me. The cause appears to be that `make
install` tries to verify that it can run the new `rustc` binary in
place, which expectedly fails due to missing libraries,

/opt/exp/rust $ make install
...
install: verifying platform can run binaries
/opt/exp/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc: 
error while loading shared libraries: libnative-4e7c5e5c.so: cannot open shared 
object file: No such file or directory
install: error: can't execute rustc binary on this platform
make: *** [install] Error 1

Surely I don't need to mangle LD_LIBRARY_PATH just to run `make
install`?

Cheers,

- Ben


pgpvw6mVdqNQT.pgp
Description: PGP signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Brian Anderson]

Other programming languages do this. C and C++ do not mandate the use of 
RPATH, and Rust not applying RPATH by default doesn't exclude people 
opting into it if they want. In this context I am also considering 
@executable_path and @loader_path to be 'RPATH', and in fact 
@loader_path is the feature being disabled on OS X.


On 07/09/2014 07:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that 
I've seen requires developers to mangle these environment variables. 
On Mac, if you don't want all of RPATH to be searched, you can use 
more specific relative paths such as @executable_path or 
@loader_path in the load command. If rust does end up sticking with 
this regression, it should replace all of the tools with little shell 
scripts that set them appropriately for you and before invoking the 
real tool.


On Wednesday, July 9, 2014, Alex Crichton > wrote:


It is indeed! You'll need to ensure that
`/Users/ilya/Library/Local/Rust/current/lib` is in your
DYLD_LIBRARY_PATH environment variable for OSX.

On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
> wrote:
> Is the following error cause by this change?
>
> % rustc -v
> dyld: Library not loaded:
>

x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib
>   Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc
>   Reason: image not found
> Trace/BPT trap
>
>
> On 9 July 2014 00:53, Brian Anderson > wrote:
>> Yes, it does.
>>
>>
>> On 07/08/2014 04:41 PM, Simon Sapin wrote:
>>>
>>> On 08/07/14 23:57, Brian Anderson wrote:

 *Running rustc directly from the build directory will no
longer work by
 default*. To do this either set LD_LIBRARY_PATH or pass
--enable-rpath
 to the configure script.
>>>
>>>
>>> Does this also apply to running a (nightly) binary
distribution from where
>>> the tarball was extracted, without installing it?
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org 
>> https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org 
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org 
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Bob Ippolito]

On Wed, Jul 9, 2014 at 9:48 AM, Patrick Walton  wrote:

> On 7/9/14 7:42 AM, Bob Ippolito wrote:
>
>> This seems like madness. No other programming language out there that
>> I've seen requires developers to mangle these environment variables.
>>
>
> Also, when installing Rust you don't have to mangle these environment
> variables, since the libraries will be placed into the right place. This
> should only impact anyone who builds from source without installing.
>

Fair enough, although you could make it work in both scenarios without
environment variables on Mac by linking with absolute paths and
-headerpad_max_install_names to the build directory and then rewriting the
load commands to the final destination with install_name_tool on install.
Probably more trouble than it's worth.


> As detailed in the meeting where this decision was made, Linux distros
> really dislike it when you mess with rpath; it's a deal-breaker in many
> cases.


Agreed, I misunderstood that everything does work correctly when installed.
My bad!

-bob
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Patrick Walton]

On 7/9/14 7:42 AM, Bob Ippolito wrote:

This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.


Also, when installing Rust you don't have to mangle these environment 
variables, since the libraries will be placed into the right place. This 
should only impact anyone who builds from source without installing.


As detailed in the meeting where this decision was made, Linux distros 
really dislike it when you mess with rpath; it's a deal-breaker in many 
cases.


Patrick

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Bob Ippolito]

On Wed, Jul 9, 2014 at 9:29 AM, Patrick Walton  wrote:

> On 7/9/14 7:42 AM, Bob Ippolito wrote:
>
>> This seems like madness. No other programming language out there that
>> I've seen requires developers to mangle these environment variables.
>>
>
> Note that rpath never worked on Windows [1], so it could never be a
> long-term solution.
>

Well, you could emulate it with runtime dynamic linking I guess, but my
point is that this is a silly regression. Why hobble every platform just
because of Windows? It's fine if you don't want to use @rpath, but you
should at least use absolute paths to libraries on Mac, if not
@executable_path or @loader_path. Windows will by default search the
equivalent of @executable_path/.. if I'm reading [1] correctly. If you
wanted a Mac solution that works in 100% of all cases the only solution is
absolute paths because dyld will ignore environment variables,
@executable_path, and @loader_path if the executable is restricted (setuid,
etc.) [2].

[1]
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx#standard_search_order_for_desktop_applications
[2] http://www.opensource.apple.com/source/dyld/dyld-239.4/src/dyld.cpp
(see processRestricted, etc.)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Patrick Walton]

On 7/9/14 7:42 AM, Bob Ippolito wrote:

This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.


Note that rpath never worked on Windows [1], so it could never be a 
long-term solution.


Patrick

[1]: 
http://stackoverflow.com/questions/107888/is-there-a-windows-msvc-equivalent-to-the-rpath-linker-flag


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Stack usage of green tasks

[Chandru]

Thanks a lot.

After about an hour of searching around, I found the RED_ZONE in stack.rs

--
Chandra Sekar.S


On Wed, Jul 9, 2014 at 8:36 PM, Alex Crichton  wrote:

> By default, each stack is allocated with a "red zone" at the end for
> running code on stack overflow, calling C functions, etc. The current
> size of the red zone is 20K.
>
> Requested stack sizes are always at least 20K, but the 20K is not
> currently added to the stack size. So for your test case when you
> request a 20K stack you're likely getting a ~10 byte stack (explaining
> the overflow), and with a 21K stack you get a 1K stack which the task
> can run in.
>
> On Wed, Jul 9, 2014 at 8:13 AM, Chandru  wrote:
> > Hi,
> >
> > This piece of code,
> >
> > #![feature(phase)]
> > #[phase(plugin)]
> > extern crate green;
> >
> > use std::io::timer;
> > use std::task::TaskBuilder;
> >
> > green_start!(main)
> >
> > fn main() {
> > for _ in range(0, 1i) {
> > TaskBuilder::new().stack_size(20*1024).spawn(proc() {
> > timer::sleep(2)
> > });
> > }
> > }
> >
> > fails with,
> >
> > task '' has overflowed its stack
> > Illegal instruction (core dumped)
> >
> > Changing the stack size to 21K works. Why does such a trivial task
> overflow
> > 20K of stack?
> >
> > --
> > Chandra Sekar.S
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Stack usage of green tasks

[Alex Crichton]

By default, each stack is allocated with a "red zone" at the end for
running code on stack overflow, calling C functions, etc. The current
size of the red zone is 20K.

Requested stack sizes are always at least 20K, but the 20K is not
currently added to the stack size. So for your test case when you
request a 20K stack you're likely getting a ~10 byte stack (explaining
the overflow), and with a 21K stack you get a 1K stack which the task
can run in.

On Wed, Jul 9, 2014 at 8:13 AM, Chandru  wrote:
> Hi,
>
> This piece of code,
>
> #![feature(phase)]
> #[phase(plugin)]
> extern crate green;
>
> use std::io::timer;
> use std::task::TaskBuilder;
>
> green_start!(main)
>
> fn main() {
> for _ in range(0, 1i) {
> TaskBuilder::new().stack_size(20*1024).spawn(proc() {
> timer::sleep(2)
> });
> }
> }
>
> fails with,
>
> task '' has overflowed its stack
> Illegal instruction (core dumped)
>
> Changing the stack size to 21K works. Why does such a trivial task overflow
> 20K of stack?
>
> --
> Chandra Sekar.S
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Stack usage of green tasks

[Chandru]

Hi,

This piece of code,

#![feature(phase)]
#[phase(plugin)]
extern crate green;

use std::io::timer;
use std::task::TaskBuilder;

green_start!(main)

fn main() {
for _ in range(0, 1i) {
TaskBuilder::new().stack_size(20*1024).spawn(proc() {
 timer::sleep(2)
});
}
}

fails with,

task '' has overflowed its stack
Illegal instruction (core dumped)

Changing the stack size to 21K works. Why does such a trivial task overflow
20K of stack?

--
Chandra Sekar.S
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Issue running documented functions from doc code w/ rustdoc

[Alex Crichton]

Doc tests are compiled as if they were clients of a library, so you'll
have to write the test assuming the rest of the source was built with
`--crate-type lib` and then import it directly.

For example, you may have to do this:

```rust
main::under_test();
```

Doc test aren't really designed with executables in mind, sadly, but
perhaps that could change!


On Wed, Jul 9, 2014 at 9:37 AM, Jeffery Olson  wrote:
> Consider the following docs:
>
>
> /// Foo
> ///
> /// ```rust
> /// under_test();
> /// ```
> pub fn under_test() {
> }
>
> doing `rustdoc main.rs --test` produces:
>
> jeff@jeff-mbp:~/src/rust-intro-presentation/Jun2014$ rustdoc main.rs --test
>
> running 1 test
> test foo::under_test_0 ... FAILED
>
> failures:
>
>  foo::under_test_0 stdout 
> :5:5: 5:15 error: unresolved name `under_test`.
> :5 under_test();
>  ^~
> error: aborting due to previous error
> task 'foo::under_test_0' failed at 'Box',
> /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:128
>
>
>
> failures:
> foo::under_test_0
>
> test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured
>
>
> Why is this? I've also tried different combinations of module imports to get
> this to work.. the only place this feature is used, extensively, is in
> libstd and it appears that maybe this is sidestepped because libstd is
> always linked by default? The manual doesn't really cover this in-depth,
> either.
>
> Any help would be appreciated.
>
> Thanks,
> Jeff
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Bob Ippolito]

This seems like madness. No other programming language out there that I've
seen requires developers to mangle these environment variables. On Mac, if
you don't want all of RPATH to be searched, you can use more specific
relative paths such as @executable_path or @loader_path in the load
command. If rust does end up sticking with this regression, it should
replace all of the tools with little shell scripts that set them
appropriately for you and before invoking the real tool.

On Wednesday, July 9, 2014, Alex Crichton  wrote:

> It is indeed! You'll need to ensure that
> `/Users/ilya/Library/Local/Rust/current/lib` is in your
> DYLD_LIBRARY_PATH environment variable for OSX.
>
> On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
> > wrote:
> > Is the following error cause by this change?
> >
> > % rustc -v
> > dyld: Library not loaded:
> >
> x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib
> >   Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc
> >   Reason: image not found
> > Trace/BPT trap
> >
> >
> > On 9 July 2014 00:53, Brian Anderson  > wrote:
> >> Yes, it does.
> >>
> >>
> >> On 07/08/2014 04:41 PM, Simon Sapin wrote:
> >>>
> >>> On 08/07/14 23:57, Brian Anderson wrote:
> 
>  *Running rustc directly from the build directory will no longer work
> by
>  default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath
>  to the configure script.
> >>>
> >>>
> >>> Does this also apply to running a (nightly) binary distribution from
> where
> >>> the tarball was extracted, without installing it?
> >>>
> >>
> >> ___
> >> Rust-dev mailing list
> >> Rust-dev@mozilla.org 
> >> https://mail.mozilla.org/listinfo/rust-dev
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org 
> > https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org 
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Alex Crichton]

It is indeed! You'll need to ensure that
`/Users/ilya/Library/Local/Rust/current/lib` is in your
DYLD_LIBRARY_PATH environment variable for OSX.

On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
 wrote:
> Is the following error cause by this change?
>
> % rustc -v
> dyld: Library not loaded:
> x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib
>   Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc
>   Reason: image not found
> Trace/BPT trap
>
>
> On 9 July 2014 00:53, Brian Anderson  wrote:
>> Yes, it does.
>>
>>
>> On 07/08/2014 04:41 PM, Simon Sapin wrote:
>>>
>>> On 08/07/14 23:57, Brian Anderson wrote:

 *Running rustc directly from the build directory will no longer work by
 default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath
 to the configure script.
>>>
>>>
>>> Does this also apply to running a (nightly) binary distribution from where
>>> the tarball was extracted, without installing it?
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Issue running documented functions from doc code w/ rustdoc

[Jeffery Olson]

Consider the following docs:


/// Foo
///
/// ```rust
/// under_test();
/// ```
pub fn under_test() {
}

doing `rustdoc main.rs --test` produces:

jeff@jeff-mbp:~/src/rust-intro-presentation/Jun2014$ rustdoc main.rs --test

running 1 test
test foo::under_test_0 ... FAILED

failures:

 foo::under_test_0 stdout 
:5:5: 5:15 error: unresolved name `under_test`.
:5 under_test();
 ^~
error: aborting due to previous error
task 'foo::under_test_0' failed at 'Box',
/home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/
diagnostic.rs:128



failures:
foo::under_test_0

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured


Why is this? I've also tried different combinations of module imports to
get this to work.. the only place this feature is used, extensively, is in
libstd and it appears that maybe this is sidestepped because libstd is
always linked by default? The manual doesn't really cover this in-depth,
either.

Any help would be appreciated.

Thanks,
Jeff
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Ilya Dmitrichenko]

Is the following error cause by this change?

% rustc -v
dyld: Library not loaded:
x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib
  Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc
  Reason: image not found
Trace/BPT trap


On 9 July 2014 00:53, Brian Anderson  wrote:
> Yes, it does.
>
>
> On 07/08/2014 04:41 PM, Simon Sapin wrote:
>>
>> On 08/07/14 23:57, Brian Anderson wrote:
>>>
>>> *Running rustc directly from the build directory will no longer work by
>>> default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath
>>> to the configure script.
>>
>>
>> Does this also apply to running a (nightly) binary distribution from where
>> the tarball was extracted, without installing it?
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Daemonizing a process

[Ilya Dmitrichenko]

Additionally, I'd like to note that modern best practice is to relay this
on the init process itself. With modern init systems, such as systemd or
launchctl, this works very nicely and application developer doesn't have to
care about daemonisation and logging is also done simply via stdout.
On 9 Jul 2014 08:33, "richo"  wrote:

> On 08/07/14 23:47 -0700, Gulshan Singh wrote:
>
>> Is there currently any way to daemonize a process in Linux? I was using
>> the
>> `daemon` function in C: http://man7.org/linux/man-
>> pages/man3/daemon.3.html.
>> I asked in the IRC but I didn't get a response.
>>
>
> There's going to be excitement with this, mostly because typically
> daemonising involves forking twice to ensure that you're reparented to
> init,
> which will result in a Really Bad Time if you're using libnative.
>
> Therefore, it's possible but only if you've not done too much stuff, which
> would be unsafe.
>
> Seperately though, rust *does* need a coherent story here. I'm just not at
> all sure what it will look like.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Daemonizing a process

[richo]

On 08/07/14 23:47 -0700, Gulshan Singh wrote:

Is there currently any way to daemonize a process in Linux? I was using the
`daemon` function in C: http://man7.org/linux/man-pages/man3/daemon.3.html.
I asked in the IRC but I didn't get a response.


There's going to be excitement with this, mostly because typically
daemonising involves forking twice to ensure that you're reparented to init,
which will result in a Really Bad Time if you're using libnative.

Therefore, it's possible but only if you've not done too much stuff, which
would be unsafe.

Seperately though, rust *does* need a coherent story here. I'm just not at
all sure what it will look like.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev