Hi,
Is there a TAR format available for MONO installation, in addition to RPM
based installation.
thanks in advance.
Ajay Gupta
Mobile : (732) 501 7585
eMail : a...@irtms.com
WebSite : http://www.iRTMS.com
___
Mono-devel-list mailing list
Hi all
Attached is a patch to libgc that will allow it to actually unmap memory
when USE_MUNMAP is defined. Currently, the unmap code just sets the
mmap flags on a region to 'no access'. The patch unlinks blocks from
the gc free list larger than a defined min size (currently 4k bytes),
that
Hey,
The attached patch implements the basics for the new MonoError struct that
will be used for error handling in the runtime.
It has only the basics to support the current exceptions the runtime handle
for it's operation.
The usage is pretty much like the one in Paolo's email on the subject:
Hi,
I still it would be easier to simply pass a int* or use an int return
value, instead of a structure which needs to be initialized/cleaned up, and
store any excess state in TLS. This is because
most code can't do anything with an error other than cleaning up and passing
it up to the
caller.
So the code below could look like:
ErrorCode err;
err = foo ();
if (err)
goto fail;
fail:
cleanup
return err;
On Thu, Aug 13, 2009 at 11:48 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I still it would be easier to simply pass a int* or use an int return
value, instead
I'm ok with using TLS for storing error information. The only issue is that
we must be carefull to avoid stale
data. The thing is that ErrorCode should be a struct so it can't be confused
with an ordinary int.
OTOH, we could do it like posix does for mutexes and get rid of the
initializer
There are a few issues with using TLS for offloading error information:
The first is that we must always copy information into it so we don't hold
onto stale
and possibly invalid data. This means it can't be used in signal context.
The second is that the information there is not as reliable as
Hi,
Zoltan Varga wrote:
Hi,
I still it would be easier to simply pass a int* or use an int return
value, instead of a structure which needs to be initialized/cleaned up, and
store any excess state in TLS. This is because
most code can't do anything with an error other than cleaning up
The runtime function mono_raise_exception is very problematic and can't be
used
as promiscuous as it currently is.
The issue is that it will unwind the current block of unmanaged code
regardless of
it's state, which can be holding locks or floating memory (that needs to be
freed).
To avoid such
Hi,
Its possible to only use the return value for error checking, we did at
Nokia, and it worked
fine, although it would require returning values using an out parameter. It
simplified error
checking code significally, since every function returned the same ErrorCode
value.
Zoltan
Rodrigo Kumpera wrote:
Finally, it makes up for good consistency to not use the return value as a
guard for error handling
because there are cases where returning NULL can mean either a valid
condition or error.
I did not propose this. The idea was to always return the error
status:
It's a good alternative, and changing return values isn't an issue since
we'll pretty much change
all signatures in the runtime anyway.
Using the return value makes it easier to write macros to remove a lot of
boiler plate code.
On Thu, Aug 13, 2009 at 8:23 PM, Zoltan Varga var...@gmail.com
12 matches
Mail list logo
