Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Brendan Eich
Marijn asked why we are not using STL in the runtime C++.

It's a good question. In Mozilla C++, we have avoided STL because we cannot take the code size and runtime costs of exceptions on all platforms.

https://bugzilla.mozilla.org/show_bug.cgi?id=200505

is worth a read if you are so inclined.

Once we gave up on STL for want of failure propagation via return value, we went in different directions on other, particular design points (raw buffer access, single-allocation hashtable [double hashing with entries as interior allocations]).

The high cost of exceptions with MSVC looks like it will endure, alas. Even with zero-cost exceptions in GCC, the RTTI hit was costly last time we checked (a while ago).

I hope this helps. I'm curious to hear from people who see a better way to go cross-platform with Rust's C++. It is 2011, after all!

/be

Begin forwarded message:

> From: marijnh <reply+c-298321-7b71fdeec2c61135dded73560e2e38d81b9e0a65 at reply.github.com>
> Date: March 10, 2011 9:31:39 PM PST
> To: brendan at mozilla.org
> Subject: Re: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]
>
> Yeah, that's a TODO. Is there a reason you're not using the STL anywhere in the runtime code?
>
> https://github.com/graydon/rust/commit/2330c96e4550d371d71822d4aa0baadba95a1253#commitcomment-298321

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20110311/5a42eb81/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Graydon Hoare
On 11-03-11 12:25 PM, Brendan Eich wrote:

> Marijn asked why we are not using STL in the runtime C++.
>
> It's a good question. In Mozilla C++, we have avoided STL because we cannot take the code size and runtime costs of exceptions on all platforms.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=200505
>
> is worth a read if you are so inclined.
>
> Once we gave up on STL for want of failure propagation via return value, we went in different directions on other, particular design points (raw buffer access, single-allocation hashtable [double hashing with entries as interior allocations]).
>
> The high cost of exceptions with MSVC looks like it will endure, alas. Even with zero-cost exceptions in GCC, the RTTI hit was costly last time we checked (a while ago).
>
> I hope this helps. I'm curious to hear from people who see a better way to go cross-platform with Rust's C++. It is 2011, after all!

I answered briefly in the pull request, but I'll elaborate here: we're
not using STL due to 1 part history and 1 part restraint.

The history is that librustrt was C for the first several years, and
we've only been C++-ifying it since about this time last year. Andreas
insisted on it.

The restraint part is that we have no story for handling or propagating
C++ exceptions into rust failures yet. We could do it with try/catch
blocks on all upcalls and native calls, possibly, but it'd take some
care and a degree of certainty that it's the right approach that I don't
yet have. So there are no exceptions used in librustrt for now.

-Graydon

Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Marijn Haverbeke
> The restraint part is that we have no story for handling or propagating C++
> exceptions into rust failures yet. We could do it with try/catch blocks on
> all upcalls and native calls, possibly, but it'd take some care and a degree
> of certainty that it's the right approach that I don't yet have. So there
> are no exceptions used in librustrt for now.

I actually think this is a sane decision. It'll require a peculiar
style of C++ programming, but is probably still less burdensome than
properly dealing with exceptions (which, on cross-language boundaries,
tends to be extremely painful).

Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Brendan Eich
On Mar 11, 2011, at 2:09 PM, Marijn Haverbeke wrote:

>> The restraint part is that we have no story for handling or propagating C++
>> exceptions into rust failures yet. We could do it with try/catch blocks on
>> all upcalls and native calls, possibly, but it'd take some care and a degree
>> of certainty that it's the right approach that I don't yet have. So there
>> are no exceptions used in librustrt for now.
>
> I actually think this is a sane decision. It'll require a peculiar
> style of C++ programming, but is probably still less burdensome than
> properly dealing with exceptions (which, on cross-language boundaries,
> tends to be extremely painful).

Agreed. For Mozillans this will be the same C++ subset we use (templates, RAII, all the best parts save exceptions).

Graydon, thanks for clarifying. You know me, I would have been pretty happy sticking with plain C :-P.

/be


Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Evan Martin
In reply to this post by Graydon Hoare
On Fri, Mar 11, 2011 at 12:48 PM, Graydon Hoare <graydon at mozilla.com> wrote:
> The restraint part is that we have no story for handling or propagating C++
> exceptions into rust failures yet. We could do it with try/catch blocks on
> all upcalls and native calls, possibly, but it'd take some care and a degree
> of certainty that it's the right approach that I don't yet have. So there
> are no exceptions used in librustrt for now.

Sorry for the naive question, but can't you use the STL without exceptions?

It seems from the bug Brendan linked to (I skimmed, I admit) they
wanted to be able to catch memory allocation failures; it's not clear
to me whether that's a desirable goal in Rust.  (It's not clear to me
if you're out of memory whether you can write any useful
non-allocating Rust code to handle the error condition.)

Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Graydon Hoare
On 12/03/2011 8:46 AM, Evan Martin wrote:

> It seems from the bug Brendan linked to (I skimmed, I admit) they
> wanted to be able to catch memory allocation failures; it's not clear
> to me whether that's a desirable goal in Rust.  (It's not clear to me
> if you're out of memory whether you can write any useful
> non-allocating Rust code to handle the error condition.)

Not at all naive. I'd like to be able to unwind from an out-of-memory
situation though. Rust domains are intended to support setting memory
budgets, on a per-domain basis, which means we may have artificial
memory ceilings far less than system ram. Can't enforce in general C
code that calls malloc(), but can (or should) be able to enforce on the
runtime structures allocated to support 'pure' rust code.

(and subprocess domains with rlimits should suffice for boxing in C code
memory use, as the process itself boxes in any segfaults or other unsafe
naughtiness :)

-Graydon

Reply | Threaded
Open this post in threaded view
|

Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]

Brendan Eich
On Mar 12, 2011, at 10:42 PM, Graydon Hoare wrote:

> On 12/03/2011 8:46 AM, Evan Martin wrote:
>
>> It seems from the bug Brendan linked to (I skimmed, I admit) they
>> wanted to be able to catch memory allocation failures; it's not clear
>> to me whether that's a desirable goal in Rust.  (It's not clear to me
>> if you're out of memory whether you can write any useful
>> non-allocating Rust code to handle the error condition.)
>
> Not at all naive. I'd like to be able to unwind from an out-of-memory situation though.

Mozilla C++ has the same constraint, which makes precise the problem with STL's containers, e.g., lacking failed-due-to-OOM return codes.

While we decorate as fallible allocation sites whose size is variable and failure-prone due to web mistakes and attacks (e.g. image height and width), and null-check, we're not yet ready to let the main process (!) fail hard if a smaller allocation walks off a cliff. And at least on Windows, it seems, it's easy to run out of VM in some cases, even in spite of overcommit being the default OS policy.

/be