[Mono-dev] [RFC v2] Handle lack of SA_SIGINFO
From: Andreas Färber
SA_SIGINFO and sigaction are part of the optional POSIX XSI feature.
In mini, there's MONO_ARCH_USE_SIGACTION but it doesn't cover everything
and it isn't available elsewhere.
v1 -> v2:
* Introduce helper macros, suggested by Paolo. (untested)
Cc: Paolo Molaro
---
Thanks Paolo, here's a draft, not yet compile-tested.
Andreas
mono/metadata/ChangeLog |7 +++
mono/metadata/console-unix.c | 36 ++--
mono/mini/ChangeLog |6 ++
mono/mini/mini-posix.c | 15 +--
4 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/mono/metadata/ChangeLog b/mono/metadata/ChangeLog
index b40af41..82c30e2 100644
--- a/mono/metadata/ChangeLog
+++ b/mono/metadata/ChangeLog
@@ -1,3 +1,10 @@
+2010-03-22 Andreas Färber
+
+ * console-unix.c (sigcont_handler, sigwinch_handler): Fix the build
+ on platforms without sigaction (Haiku).
+
+ Code is contributed under MIT/X11 license.
+
2010-03-22 Geoff Norton
* locales.c: Its possible for CFStringGetCStringPtr
diff --git a/mono/metadata/console-unix.c b/mono/metadata/console-unix.c
index 99e0754..8a7da12 100644
--- a/mono/metadata/console-unix.c
+++ b/mono/metadata/console-unix.c
@@ -262,10 +262,32 @@ sigint_handler (int signo)
in_sigint = FALSE;
}
+#define SIGHANDLER_VALID(sigh) \
+ ((sigh) != NULL && \
+(sigh) != (void *)SIG_DFL && \
+(sigh) != (void *)SIG_IGN)
+
+#ifdef SA_SIGINFO
+#define SIGHANDLER_SIGNATURE int signo, void *the_siginfo, void *data
+#define INVOKE_SIGHANDLER_IF_VALID(siga) G_STMT_START \
+ if ((siga).sa_flags & SA_SIGINFO) { \
+ if (SIGHANDLER_VALID((siga).sa_sigaction)) \
+ (*(siga).sa_sigaction) (signo, the_siginfo,
data); \
+ } else if (SIGHANDLER_VALID((siga).sa_handler)) \
+ (*(siga).sa_handler) (signo); \
+ G_STMT_END
+#else
+#define SIGHANDLER_SIGNATURE int signo
+#define INVOKE_SIGHANDLER_IF_VALID(siga) G_STMT_START \
+ if (SIGHANDLER_VALID((siga).sa_handler)) \
+ (*(siga).sa_handler) (signo); \
+ G_STMT_END
+#endif
+
static struct sigaction save_sigcont, save_sigint, save_sigwinch;
static void
-sigcont_handler (int signo, void *the_siginfo, void *data)
+sigcont_handler (SIGHANDLER_SIGNATURE)
{
// Ignore error, there is not much we can do in the sigcont handler.
tcsetattr (STDIN_FILENO, TCSANOW, &mono_attr);
@@ -274,24 +296,18 @@ sigcont_handler (int signo, void *the_siginfo, void *data)
write (STDOUT_FILENO, keypad_xmit_str, strlen
(keypad_xmit_str));
// Call previous handler
- if (save_sigcont.sa_sigaction != NULL &&
- save_sigcont.sa_sigaction != (void *)SIG_DFL &&
- save_sigcont.sa_sigaction != (void *)SIG_IGN)
- (*save_sigcont.sa_sigaction) (signo, the_siginfo, data);
+ INVOKE_SIGHANDLER_IF_VALID (save_sigcont);
}
static void
-sigwinch_handler (int signo, void *the_siginfo, void *data)
+sigwinch_handler (SIGHANDLER_SIGNATURE)
{
int dims = terminal_get_dimensions ();
if (dims != -1)
cols_and_lines = dims;
// Call previous handler
- if (save_sigwinch.sa_sigaction != NULL &&
- save_sigwinch.sa_sigaction != (void *)SIG_DFL &&
- save_sigwinch.sa_sigaction != (void *)SIG_IGN)
- (*save_sigwinch.sa_sigaction) (signo, the_siginfo, data);
+ INVOKE_SIGHANDLER_IF_VALID (save_sigwinch);
}
void
diff --git a/mono/mini/ChangeLog b/mono/mini/ChangeLog
index f15d276..c1b60ba 100755
--- a/mono/mini/ChangeLog
+++ b/mono/mini/ChangeLog
@@ -1,3 +1,9 @@
+2010-03-22 Andreas Faerber
+
+ * mini-posix.c: Fix the build on platforms without SA_SIGINFO (Haiku).
+
+ Code is contributed under MIT/X11 license.
+
2010-03-22 Zoltan Varga
* exceptions-amd64.c: Add support for OpenBSD which has no
UCONTEXT_GREGS.
diff --git a/mono/mini/mini-posix.c b/mono/mini/mini-posix.c
index 823d93b..f53a850 100644
--- a/mono/mini/mini-posix.c
+++ b/mono/mini/mini-posix.c
@@ -82,13 +82,17 @@ save_old_signal_handler (int signo, struct sigaction
*old_action)
mono_trace (G_LOG_LEVEL_DEBUG, MONO_TRACE_CONFIG,
"Saving old signal handler for signal %d.",
signo);
+#ifdef SA_SIGINFO
if (! (old_action->sa_flags & SA_SIGINFO)) {
+#endif
handler_to_save->sa_handler = old_action->sa_handler;
+#ifdef SA_SIGINFO
} else {
#ifdef MONO_ARCH_USE_SIGACTION
handler_to_save->sa_sigaction = old_action->sa_sigaction;
#endif /* MONO_ARCH_USE_SIGACTION */
}
+#endif
handler_to_save->sa_mask = old_action->sa_mask;
handler_to_save->sa_flags = old_action->sa_flags;
@@ -129,13 +133,17 @@ SIG_HANDLER_SIGNATURE (mono_chain_signal)
Re: [Mono-dev] [PATCH] Don't rely on SIGIO
Am 22.03.2010 um 21:24 schrieb Jonathan Pryor: > On Sun, 2010-03-21 at 23:44 +0100, Andreas Färber wrote: >> SIGIO is not part of POSIX, Haiku does not support it. > > You might want to mention that fact in the ChangeLog, otherwise we'll > need to care why SIGIO is special but not SIGWINCH (which according to > signal(7) is from 4.3BSDand Sun). > > Otherwise, the patch looks OK. Please commit. Done, thanks. Applied to trunk in r154029. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Don't rely on SIGIO
On Sun, 2010-03-21 at 23:44 +0100, Andreas Färber wrote: > SIGIO is not part of POSIX, Haiku does not support it. You might want to mention that fact in the ChangeLog, otherwise we'll need to care why SIGIO is special but not SIGWINCH (which according to signal(7) is from 4.3BSDand Sun). Otherwise, the patch looks OK. Please commit. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Regex.Match(string, int, int) behaves differently than Microsoft's implementation
Hello,
> Text of the bug report is as follows:
> Certain regular expressions will behave differently on Mono when calling
> Regex.Match(string, int, int). In particular the expression
>
> new Regex("^quick$").Match("The quick brown fox jumps over the lazy dog.", 4,
> 5).Success
>
> evaluates to true in Microsoft's implementation, but false in Mono. It appears
> that in Microsoft's implementation, the results of the method are comparable
> to
> calling string.Substring() on the string being passed in, except that indexes
> are still reported in terms of the original string.
Seems like a genuine bug to me.I do not think there is anything like a quick
fix, only the correct fix.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug 582502 - System.Linq.Enumerable.OrderByDescending is not a stable sort
It would appear that the Compare method in SortSequenceContext.cs (lines 58 - 70 revision 152310) does not allow for equality. If a comparison returns zero on line 60 and a non-zero child context comparison is never found then Compare will return first_index - second_index on line 66 (which is always going to give you a non-zero number unless you do something silly like compare an index to its self). I've fixed this by replacing line 66 to simply return zero in the equality case. Unfortunately this breaks the QuickSort.cs implementation. That said, QuickSort by definition is not a stable sort (there are variants which are, but it does not appear that the current implementation is a stable variant). To solve this; I replaced QuickSort with MergeSort and everything works as it is supposed to. I'm not sure if the desired solution is to use MergeSort or a stable QuickSort, but if you'd like a MergeSort implementation I would be happy to supply it. Thanks, Richard Kiene ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Regex.Match(string, int, int) behaves differently than Microsoft's implementation
On Mon, Mar 22, 2010 at 3:52 PM, Tom Philpot wrote:
> So we've reported this bug here:
> https://bugzilla.novell.com/show_bug.cgi?id=474154
>
> Text of the bug report is as follows:
> Certain regular expressions will behave differently on Mono when calling
> Regex.Match(string, int, int). In particular the expression
>
> new Regex("^quick$").Match("The quick brown fox jumps over the lazy dog.",
> 4,
> 5).Success
>
> evaluates to true in Microsoft's implementation, but false in Mono. It
> appears
> that in Microsoft's implementation, the results of the method are
> comparable to
> calling string.Substring() on the string being passed in, except that
> indexes
> are still reported in terms of the original string.
>
> As a side note, the expression
>
> new Regex("^quick").Match("The quick brown fox jumps over the lazy dog.",
> 4).Success
>
> evaluates to false both in Microsoft's implementation and in Mono. Any fix
> to
> the former should not break the latter.
> Before I went digging into the bug, I thought I'd ask if any of the devs
> had a quick fix.
>
>
Fixing bugs in the regexp engine is really really hard given how subtle is
it's behavior.
Providing a good suite of tests is a great way forwards having it fixed.
I don`t think short-circuiting and checking for "^???$" is the right fix
since the check is
pretty complex due to other regexp rules that can be inside.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Regex.Match(string, int, int) behaves differently than Microsoft's implementation
So we've reported this bug here:
https://bugzilla.novell.com/show_bug.cgi?id=474154
Text of the bug report is as follows:
Certain regular expressions will behave differently on Mono when calling
Regex.Match(string, int, int). In particular the expression
new Regex("^quick$").Match("The quick brown fox jumps over the lazy dog.", 4,
5).Success
evaluates to true in Microsoft's implementation, but false in Mono. It appears
that in Microsoft's implementation, the results of the method are comparable to
calling string.Substring() on the string being passed in, except that indexes
are still reported in terms of the original string.
As a side note, the expression
new Regex("^quick").Match("The quick brown fox jumps over the lazy dog.",
4).Success
evaluates to false both in Microsoft's implementation and in Mono. Any fix to
the former should not break the latter.
Before I went digging into the bug, I thought I'd ask if any of the devs had a
quick fix.
Thanks,
Tom
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] stressing mono and xsp
Been testing xsp with 500 simultaneous users per second and found out two
issues in code. Also had been getting some annoying exceptions.
-Connection.cs (i sink the disposed exception, because sometimes the socket is
closed on endrequest right away)
while (!stop && (UnfinishedRequests || keep_alive));
if (requests.Count == 0) {
try
{
socket.Close ();
server.EndConnection (this);
server.ReleaseBuffers (receive_buffer, send_buffer);
}
catch (System.ObjectDisposedException)
{
//do nothing, already disposed on endrequest
}
}
-Server.cs (on RequestCount property)
/*
foreach (Connection c in connections)
requests += c.RequestCount;
*/
for(int i=0;i___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve System.Net.WebClient's CreateUri(Uri address) query string handling
My apologies, I thought from the mdsn documentation it always appened the QueryString from WebClient - testing it on windows this morning does confirm your statement. Thanks again for the fix. Jon --- On Mon, 3/22/10, Gonzalo Paniagua Javier wrote: > From: Gonzalo Paniagua Javier > Subject: Re: [Mono-dev] [PATCH] Improve System.Net.WebClient's CreateUri(Uri > address) query string handling > To: "Jon Herron" > Cc: mono-devel-list@lists.ximian.com > Date: Monday, March 22, 2010, 5:31 AM > On Sun, 2010-03-21 at 21:34 -0700, > Jon Herron wrote: > > Thanks for the commit, there still seems to be an > issue when > > WebClient's QueryString property is set - it appears > to be ignoring it > > if the address has a query string as well, instead of > appending it to > > address' query string. I've included a patch > that works with my test > > case below, any feedback is welcome. > > When I tested that, MS ignored WebClient.QueryString in > presence of a > query string in the actual URL... > > -Gonzalo > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [RFC] Handle lack of SA_SIGINFO
On 03/22/10 Andreas Färber wrote:
> SA_SIGINFO and sigaction are part of the optional POSIX XSI feature.
> In mini, there's MONO_ARCH_USE_SIGACTION but it doesn't cover everything
[...]
> +#ifdef SA_SIGINFO
> + if (save_sigcont.sa_flags & SA_SIGINFO) {
> if (save_sigcont.sa_sigaction != NULL &&
> save_sigcont.sa_sigaction != (void *)SIG_DFL &&
> save_sigcont.sa_sigaction != (void *)SIG_IGN)
> (*save_sigcont.sa_sigaction) (signo, the_siginfo, data);
> + } else
> +#else
> + if (save_sigcont.sa_handler != NULL &&
> + save_sigcont.sa_handler != (void *)SIG_DFL &&
> + save_sigcont.sa_handler != (void *)SIG_IGN)
> + (*save_sigcont.sa_handler) (signo);
> +#endif
> }
These kind of changes are quite ugly. Please introduce a cpp macro
that handles this stuff, so that the code doesn't become a forest of
#ifdefs.
Something like:
#define INVOKE_SIGHANDLER_IF_VALID (siga,signo,sinfo,data) do {\
if (((siga)->sa_flags & SA_SIGINFO) && (siga)->sa_sigaction != NULL &&
...) \
(siga)->sa_sigaction ((signo), (sinfo), (data));\
} while (0)
and the equialent for the non-SA_SIGINFO case.
lupus
--
-
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Scenario with MonoReflectionType
Hello,
Thanks, this is all I need.
Regards, Laurent Etiemble.
2010/3/22 Robert Jordan
> On 22.03.2010 09:38, Laurent Etiemble wrote:
> > Hello,
> >
> > I am working on embedding Mono and I am stuck with the following issue: I
> > would like to get a MonoClass or a MonoType instance from
> > a MonoReflectionType instance.
> >
> > So, imagine I have an internal call with the following signature:
> >
>
> There is no way to the a MonoType* from a MonoReflectionType*
> than getting it from Type.TypeHandle.Value.
>
> Here is a solution for your problem:
>
>
> [MethodImplAttribute(MethodImplOptions.InternalCall)]
> public static extern String GetName(IntPtr typeHandle);
>
> public static String GetName(Type type)
> {
> return GetName (type.TypeHandle.Value);
> }
>
> >
> > Then, the implementation should look like:
> >
> > MonoString *ves_icall_XXX_ GetName(MonoReflectionType *type) {
>
>
> MonoString *ves_icall_XXX_ GetName(MonoType *type)
> {
> ...
> }
>
>
> Robert
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Scenario with MonoReflectionType
On 22.03.2010 09:38, Laurent Etiemble wrote:
> Hello,
>
> I am working on embedding Mono and I am stuck with the following issue: I
> would like to get a MonoClass or a MonoType instance from
> a MonoReflectionType instance.
>
> So, imagine I have an internal call with the following signature:
>
There is no way to the a MonoType* from a MonoReflectionType*
than getting it from Type.TypeHandle.Value.
Here is a solution for your problem:
[MethodImplAttribute(MethodImplOptions.InternalCall)]
public static extern String GetName(IntPtr typeHandle);
public static String GetName(Type type)
{
return GetName (type.TypeHandle.Value);
}
>
> Then, the implementation should look like:
>
> MonoString *ves_icall_XXX_ GetName(MonoReflectionType *type) {
MonoString *ves_icall_XXX_ GetName(MonoType *type)
{
...
}
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Embedding Scenario with MonoReflectionType
Hello,
I am working on embedding Mono and I am stuck with the following issue: I
would like to get a MonoClass or a MonoType instance from
a MonoReflectionType instance.
So, imagine I have an internal call with the following signature:
[MethodImplAttribute(MethodImplOptions.InternalCall)]
public static extern String GetName(Type type);
Then, the implementation should look like:
MonoString *ves_icall_XXX_ GetName(MonoReflectionType *type) {
MonoType *theType = mono_XXX(type); // <-- Don't seem to exist in the
embedding API
// xor
MonoClass *theClass = mono_YYY(type); // <-- Don't seem to exist in the
embedding API
const char *name = mono_type_get_name(theType);
// xor
const char *name = mono_class_get_name(theClass);
return mono_string_new(mono_domain_get(), name);
}
I have taken a look to the Marshal internal calls, but they access directly
the MonoReflectionType structure.
Is there any public API to get a MonoClass or a MonoType instance from
a MonoReflectionType instance ?
Regards, Laurent Etiemble.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for ilasm (ldc.i4 opt)
Hi Rodrigo,
I don't have an svn account, but I'll soon stop working on our gcc4cli
project so I think, for the moment, it is not worth I have one (my
successor may ask for one, when we've found him/her).
I simply would like to add this patch (+ another concerning local
variable accesses), would you mind commiting it please?
Regards,
Thierry Lafage.
Rodrigo Kumpera a écrit :
> Patch looks good, do you have a SVN account?
>
>
> On Wed, Mar 17, 2010 at 2:22 PM, Thierry Lafage
> mailto:thierry.laf...@inria.fr>> wrote:
>
> Hi all,
>
> Here is a small patch for ilasm which makes it replace ldc.i4 with
> short forms when possible.
> Note that I'm a C# and monodevelop newbie (but I tried to respect
> the coding guidelines).
> I suggest to add the "-opt:ldc" because I would like to add the
> same kind of optimization for ldloc/stloc (use short forms when
> possible). For this latter one, the command line option could be
> "-opt:loc" (and we could add "-opt:all" to enable both at once).
> I think the impact of such a patch is quite limited, but it's
> important for us (the gcc4cli team) since we rely on ilasm to
> assemble the CIL code produced by our compiler. And these
> "optimizations" tasks are better suited to the assembler than to
> the compiler itself.
>
> Regards,
> Thierry Lafage.
>
>
> Index: ilasm/Driver.cs
> ===
> --- ilasm/Driver.cs (revision 153715)
> +++ ilasm/Driver.cs (working copy)
> @@ -20,6 +20,8 @@
>
> public class Driver {
>
> + internal static bool opt_ldc = false;
> +
> enum Target {
> Dll,
> Exe
> @@ -270,6 +272,10 @@
>else
>keyname =
> command_arg;
>break;
> +case "opt":
> + if ("ldc" ==
> command_arg)
> +
> Driver.opt_ldc = true;
> + break;
> case "scan_only":
> scan_only = true;
> break;
> @@ -344,6 +350,7 @@
> " /exe
> Compile to executable.\n" +
> " /dll
> Compile to library.\n" +
> " /debug
> Include debug information.\n" +
> +" /opt:ldc
> Optimize ldc instructions (use shorter forms when possible).\n" +
>" /key:keyfile
> Strongname using the specified key file\n" +
>" /key:@container
> Strongname using the specified key container\n" +
> "Options can be of the
> form -option or /option\n");
> Index: ilasm/codegen/IntInstr.cs
> ===
> --- ilasm/codegen/IntInstr.cs (revision 153715)
> +++ ilasm/codegen/IntInstr.cs (working copy)
> @@ -27,9 +27,35 @@
> public override void Emit (CodeGen code_gen,
> MethodDef meth,
> PEAPI.CILInstructions cil)
> {
> -cil.IntInst (op, operand);
> -}
> + if (Driver.opt_ldc && op ==
> PEAPI.IntOp.ldc_i4) {
> + if (operand >= -1 && operand <= 8)
> + cil.Inst (getOptLdcOp
> (operand));
> + else if (operand >= -128 &&
> operand <= 127)
> + cil.IntInst
> (PEAPI.IntOp.ldc_i4_s,
> + operand);
> + else
> + cil.IntInst (op, operand);
> + } else
> + cil.IntInst (op, operand);
> + }
>
> + private PEAPI.Op getOptLdcOp (int operand)
> + {
> + switch (operand) {
> + case -1: return PEAPI.Op.ldc_i4_m1;
> + case 0: return PEAPI.Op.ldc_i4_0;
> + case 1: return PEAPI.Op.ldc_i4_1;
> + case 2
