On 5/24/12 12:40 PM, Bennie Kloosteman wrote: >> * The system _must_ not prevent developers from calling C code from Rust. >> * The system _must_ not prevent developers from passing a pointer to a >> Rust function to C code that will call back to it. >> * The system _must_ not prevent, some day, developers from calling Rust >> from JavaScript. >> * The system _must_ not prevent, some day, developers from calling >> JavaScript from Rust. > > These should be unsafe - I believe this is the case with rust.
I am not sure if you mean this in relation with all four points or with the last one. So, indeed, I see no reason to change the fact that calls to C are considered unsafe. For calls to JavaScript, I have not given it much thought. I suppose that they could be either unsafe or somehow managed. >> * Issues _must_ not be restricted to integers (or to one single type). > > Yes but returning error codes and then looking up further issue > detail separately is quite useful since your passing around little > information it gives the highest chance in a partially unsafe > environment of working out what happened . eg if the stack is > corrupted or you have major issues its useful that the error is memory > logged ( eg in ring 0 in a rust based kernel ) and then retrieved . > A simple integer return value has a much better chance.. Interesting point. Are we talking about implementing Servo with a ring-like mechanism? If so, I suspect that we may simply not want this kind of issues to cross ring boundaries. Otherwise, if we let high-level issues cross boundaries, we could be sending closures, for instance, which sounds like a bad idea. For the moment, I believe that we should assume that the issue mechanism will not be used for crossing ring boundaries. > This could be a 64 bit value with the low 32 bits the error and the > upper 32 bit some sort of hash code. > > A more detailed but not guaranteed representation should be a detailed > structure. with time stamps etc I would even say this detail should > be created asynchronously via a new task while the actual error is > returned immediately . > > errno is a pain , but not because it returns an int but because all > the information you can retrieve on it is a error string. > > Actually you could log all the detail and just reference an index to > the log , Though this would require recent log entries to be > recallable and have more detail in the log fields eg error category > and level ( which are useful in a log anyway) All these are interesting points, although perhaps they arrive a little too early in the thread :) >> * The default behavior in case of untreated issue _should_ be to >> gracefully kill the task or the application. > > If its integrated with tracing and logging the default behaviour > depends on the error type > > eg Trace , Log, Warning or Error continue , Critical = halt. A tracer/logger with this kind of semantics could certainly be built on top of the issue mechanism. I tend to believe that that they should be integrated from the start, though. >> * Whenever an untreated issue kills a task/application, it _should_ >> produces a report usable by the developer for fixing the issue. >> * It _should_ be possible to deactivate that killing behavior. There >> _may_ be limitations. >> * It _should_ be possible to deactivate that killing behavior >> conditionally (i.e. only for some errors). > > also a task can monitor child tasks for errors ( I don't think Rust > has events but something like that) and choose on error to abort or > continue depending on the error condition. . Sounds interesting. I suspect (but I am not sure) that this is something that could/should be built on top of a more elementary issue mechanism. Could you provide a scenario that we could use as a working base? >> * The system _should_ eventually have a low runtime cost – in >> particular, the case in which no killing happens should be very fast. > > I don't think the performance of an error system is important at all , > its more important to have stack and meta data to resolve the issue > especially in debug builds ( and meta data is very slow) . This leads > to people using errors to pass/check state which is a bad habit Could you elaborate on that last sentence? I am starting to believe that collecting [meta]data might be something that we want to configure on a usage basis. For instance, in function |move|, introduced a few e-mails ago (I just reposted it at https://gist.github.com/2781413 for convenience), we may be interested in the metadata of calls to lines 10 and 12, but gathering metadata for the calls in lines 2 and 6 is generally a waste of resources. If we think of this as exceptions, it could be that we want several the ability to specify if/when we want to gather metadata at the level of an equivalent of |try|. I believe that this fits nicely with what Graydon had in mind, by the way. > I would add > * Tasks are the error scope / unit > > * should we have an exception like syntax that automatically creates a > sub task for the embedded statements ( and hence means those > statements cannot result in failure of the parent tasks) . Since > errors are scoped to the task , the easy way is a new task . This looks quite heavyweight to me. So, if you don't care about performance, sure. But I'm clinging to the hope that we can make something faster, so I disagree for the moment :) > * It should be integrated with tracing and logging. Looks like two distinct things to me. Why couldn't you build a tracing + logging tool on top of it? > * custom tracing , error and log handlers should be possible and > dynamically configurable, Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
