on the dartium usage pattern:
- Dart_GetNativeStringArgument (gets a String object, peer etc. directly from
the native arguments)
- Dart_SetWeakHandleReturnValue (allows a weak handle to be passed to the
return value, this ensures a new local handle does not have to be created
from a weak handle just to return a value)
- Dart_StringGetProperties (gets some common properties of a string, avoids
multiple API calls to set up a native string)
R=srdjan@google.com, vsm@google.com
Review URL: https://codereview.chromium.org//22632010
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26046 260f80e4-7a28-3924-810f-c04153c831b5
- Added unimplemented versions of Dart_ByteArrayAcquireData and
Dart_ByteArrayReleaseData
- Added infrastructure to prevent callbacks into an API function that
allocates a new object on the Dart heap or invokes dart code.
- Removed the old Dart_ByteArrayGet* access functions as it was felt that
they have become redundant once we provide direct access to the internal
data pointers.
- Removed DARTSCOPE_NOCHECKS as it seems to be redundant after the change
to not create explicit stack zones on each Dart API call.
Review URL: https://codereview.chromium.org//12036098
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@17958 260f80e4-7a28-3924-810f-c04153c831b5
Instead of passing a size in bytes to the allocation function, we now
have a templatized Alloc function:
zone->Alloc<Type>(len)
This is better for security, as we can check for integer overflow in
the size computation before performing the allocation. Before, we
often failed to check this.
Review URL: https://chromiumcodereview.appspot.com//10836061
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@10254 260f80e4-7a28-3924-810f-c04153c831b5
Prologue weak persistent handles are similar to weak persistent
handles but exhibit different behavior during garbage collections that
invoke the prologue and epilogue callbacks. While weak persistent
handles always weakly reference their referents, prologue weak
persistent handles weakly reference their referents only during a
garbage collection occurs that invokes the prologue and epilogue
callbacks. During all other garbage collections, prologue weak
persistent handles strongly reference their referents.
Review URL: https://chromiumcodereview.appspot.com//9655011
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5445 260f80e4-7a28-3924-810f-c04153c831b5
The native port callback is now passed the message as a decodes
Dart_CMessage structure. The Dart_CMessage structure is allocated
in a zone and the callback receiving it should expect the
lifetime to be controlled by the caller.
Added support for zones which do not require a current
isolate. Changed the GrowableArray to support allocating in
aprovided zone instead of the zone for the current isolate.
R=turnidge@google.com, asiva@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9325022
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@4068 260f80e4-7a28-3924-810f-c04153c831b5
Dart_NewNativePort creates a port associated with a C handler
function. When messages come in on this port, they are forwarded to
the C function for processing.
To support this, refactored PortMap so that it operates on a new
MessageHandler type instead of directly on Isolates.
For now, native ports have a dedicated single thread. Eventually we
will back native ports (and possibly Isolates as well) by a shared
thread pool.
Review URL: https://chromiumcodereview.appspot.com//9169063
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@3804 260f80e4-7a28-3924-810f-c04153c831b5
(1)
No longer give embedders direct access to inter-isolate messages.
Instead, keep these messages in an internal queue and rely on the
embedder only to provide notifications. This simplifies the api in
numerous ways:
- post message callback drops parameters and becomes message notify callback.
- close port callback goes away
- Dart_Message type goes away
- Dart_HandleMessage gets a simpler signature
Updated the custom_isolate_test to show what use of the new apis looks like.
(2)
Begin to add support for out-of-band (OOB) messages. These messages
supercede regular messages in the queue. We will attempt to deliver
these messages even while code is running, by using the isolate
interrupt mechanism. These messages are not user-visible. They will
be used by the runtime internally to implement things like reflection.
Renamed PortMessage to Message.
Refactored message sending apis in PortMap and Isolate.
Modified MessageQueue to be aware of multiple priorities.
Modify Dart_HandleMessage to process multiple OOB messages
Review URL: https://chromiumcodereview.appspot.com//9182001
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@3562 260f80e4-7a28-3924-810f-c04153c831b5
things that may go wrong while invoking the dart api.
Here are the four types of error:
- ApiError = the user misused one of the dart apis
- LanguageError = a language-level problem, e.g. compiler error
- UnhandledException = an uncaught exception made its way to the embedder
- UnwindError = a forced isolate interrupt
This cl is the first of a series. I plan to move the point of
creation for LanguageErrors into the Parser, etc. I also plan to move
the longjmp's out of dart_api_impl.cc. I also also plan to implement
UnwindErrors later.
(Copied from Issue 9085031 due to subversion problems)
Review URL: http://codereview.chromium.org//9166016
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@3168 260f80e4-7a28-3924-810f-c04153c831b5
CHECK_ISOLATE -- make sure that there is a current isolate.
CHECK_NO_ISOLATE -- the opposite.
CHECK_ISOLATE_SCOPE -- make sure that there is a current isolate and it has an API scope.
DARTSCOPE changes to call CHECK_ISOLATE_SCOPE. If you don't want
that, use DARTSCOPE_NOCHECKS.
Went through all of the DART_EXPORT function and made sure they all
had the appropriate checking.
Rewrite DARTSCOPE a bit to avoid evaluating the macro param multiple
times.
Review URL: http://codereview.chromium.org//8733011
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1990 260f80e4-7a28-3924-810f-c04153c831b5
--
Terminology change: invalid handles are now called error handles.
Unhandled exceptions used to be a kind of valid handle. Now they are
a kind of error handle.
For the Dart_Invoke* functions, this means that the standard
error-checking blob drops from two tests to one test and is
harder to mess up.
Many other Dart api functions (Dart_ToString, for example) previously
dealt with unhandled exceptions by turning them into terse error
messages. Now these functions preserve information about the
exceptions and generate better error messages.
Changed Dart_HandleMessage to return success/failure. It seemed to fit.
--
Details:
Dart_IsValid becomes Dart_IsError (negated sense).
Dart_GetError now knows how to print a stack trace semi-nicely.
Dart_ExceptionOccurred -> Dart_IsUnhandledException.
Renamed ApiFailure class to ApiError to fit better.
ApiError now has a "data" pointer that points to either an error
message string or to an unhandled exception object.
Documentation changes aplenty.
Review URL: http://codereview.chromium.org//8501034
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1470 260f80e4-7a28-3924-810f-c04153c831b5
- Dart_Result is gone. Dart_Handle mostly replaces it.
- Name/signature changes
- IsValidResult -> IsValid
- GetErrorCString -> GetError
- many more...
- Make details of persistent handle freelist private.
- Add persistent "True" handle to api state.
Things I am not doing in this changelist:
- Documentation updates
Review URL: http://codereview.chromium.org//8380020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@778 260f80e4-7a28-3924-810f-c04153c831b5
asiva@google.com