Re: [Mono-dev] Single thread scheduler for Threading.Timers patch
On Tue, 2006-06-13 at 23:04 -0700, Rafael Ferreira wrote: Howdy, The attached patch changes the current Threading.Timer class to use a single thread scheduler instead of the current 1 thread per timer logic. I also spent a lot of time working on the Timer unit tests so they more consistently pass as well as fixing the NotWorking tests. Some key features include: * A single thread handles firing all timer jobs thus allowing a much greater number of Timers to be defined - Fixing bug #65734 * Timer scheduler is only started after the first System.Threading.Timer is created (lazy init) * Timer scheduler thread dies if there are no more timer jobs in its Job queue (early termination) * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG environment variable Of course, I don't expect this patch to be accepted without some degree of scrutiny so comments/concerns are appreciated and I can commit the code once we're all comfortable with it. You are using wrong coding style in some places (f() instead of f ()). -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance of Invoke
I don't think that design is very good, for a number of reasons:
- Performance will suck (due to reflection)
- It's highly magical (due to reflection)
- Documentation will likely be problematic (due to magic)
A cleaner, faster, and more easily documented version would be this
(untested):
//defined in class library
class FsmEvent {}
delegate void FsmEventHandler (object o, FsmEvent e);
class Fsm
{
//events can be posted to the event queue and read from the
// dispatch loop from a thread...
public QueuefsmEvent QueueEvent;
public event FsmEventHandler FsmEvent;
public void dispatchEvent()
{
FsmEv e = Queue.Dequeue();
FsmEvent (this, e);
}
}
// defined in user library
class UserFsmEvent : FsmEvent{}
class FsmTimerEvent : FsmEvent{}
class FsmUser
{
public void MyHandler (object o, FsmEvent e)
{
bool handled = false;
if (!handled) handled = HandleUser (e as UserFsmEvent);
if (!handled) handled = HandleTimer (e as
FsmTimerEvent);
if (!handled) {/* default behavior */}
}
private bool HandleUser (UserFsmEvent e)
{
if (e == null) return false;
/* ... */
return true;
}
private bool HandleTimer (UserFsmEvent e)
{
if (e == null) return false;
/* ... */
return true;
}
}
In short, use an event in Fsm to invoke a FsmEventHandler delegate,
which FsmUser.MyHandler matches. FsmUser.MyHandler then uses normal
(fast!) type casting with `as' to delegate to the appropriate handler.
Sadly, this requires more work on the User's part, but (1) the work is
highly idiomatic, and (2) gives the user complete control, (3) allows
for saner behavior (less magic), and (4) provides excellent
performance. (The only way to get better performance would be to use a
virtual function, and require that FsmUser inherit from Fsm and override
some virtual/abstract method declared within Fsm.)
If the above still doesn't work for you, you'd have to lookup a delegate
type from the FsmEvent type name, e.g. require that all *FsmEvent types
have a matching *FsmEventHandler delegate within the same assembly, then
use Reflection to lookup this *FsmEventHandler type and create an
appropriate delegate.
This won't help you much, though, unless you cache the delegate lookups
within Fsm; always re-looking up this information won't help performance
at all.
- Jon
On Tue, 2006-06-13 at 22:06 -0500, Tim Michals wrote:
I've tested on NET the performance of invoke compared to Delegate,
Delegate
is several orders of magnitude faster. The problem I'm having is
creating a
delegate with the proper type, Delegate.CreateDelegate requires the
delegate
type to be defined. But the base library only knows the base type not
the
class defined in the user code
For example...(This is a very basic pseudo code) Looking for better
perfomance then using Invoke..I read some methods of creating LCG but
is
that the only way?
//defined in class library
class fsmEvent{}
class fsm
{
//events can be posted to the event queue and read from the
dispatch
loop from a thread...
public QueuefsmEvent QueueEvent;
public void dispatchEvent()
{
fsmEv = Queue.dequeue();
Type t= userFsm.GetType();
MethodInfo mFsmEvent = t.GetMethod( ... based on fsmEv type,
match
the parameter list)
// invoke proper method
mFsmEvent.Invoke(userFsm,new
object[]{ fsmLoop.fsmEventList[0]});
// Want to replace this is some type of Delegate for performance...
}
}
// define in user library
class userFsmEvent : fsmEvent{}
class fsmTimerEvent : fsmEvent{}
class fsmUser
{
public void hander1(fsmEvent ev){}
public void handler2(fsmTimerEvent ev){}
public void hander3(userFsmEvent ev){}
}
___
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] Bug in System.Web.UI.WebControls.BaseDataList
Sorry, I've forgot the NET_2_0 ifdef, I will recommit. Vladimir Krasnov -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gonzalo Paniagua Javier Sent: Tuesday, June 13, 2006 5:58 PM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Bug in System.Web.UI.WebControls.BaseDataList On Wed, 2006-05-24 at 06:07 -0700, Vladimir Krasnov wrote: Hello, There is a bug in BaseDataList, its method OnDataSourceViewChanged is not called when data source is changed. Look attached sample that reproduces the bug and the patch that fixes it. I will commit if no one objects. Your commit broke the 1.1 build and I've reverted it. -Gonzalo ___ 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
[Mono-dev] Patch for bug #78626
Hi,
The attached patch fixes bug
http://bugzilla.ximian.com/show_bug.cgi?id=78626
If think the code for the caching of already compiled
pages/controls/whatever and especially the dependency tracking between
those needs a complete rewrite, but this should do for now.
Is it okay to commit?
- Juraj
(this time _including_ the promised patch)
Index: System.Web.UI/TemplateParser.cs
===
--- System.Web.UI/TemplateParser.cs (revision 61599)
+++ System.Web.UI/TemplateParser.cs (working copy)
@@ -364,6 +364,14 @@
dependencies.Add (filename);
}
+ internal virtual string[] GetLowerDependencies ()
+ {
+ int idx = dependencies.IndexOf (inputFile);
+ string[] deps = new string [dependencies.Count - idx];
+ dependencies.CopyTo (idx, deps, 0, deps.Length);
+ return deps;
+ }
+
internal virtual void AddAssembly (Assembly assembly, bool fullPath)
{
if (assembly.Location == )
Index: System.Web.UI/TemplateControlParser.cs
===
--- System.Web.UI/TemplateControlParser.cs (revision 61599)
+++ System.Web.UI/TemplateControlParser.cs (working copy)
@@ -137,6 +137,7 @@
}
AddAssembly (type.Assembly, true);
+AddDependency (realpath);
RootBuilder.Foundry.RegisterFoundry (tagprefix, tagname, type);
return;
}
Index: System.Web.Compilation/CachingCompiler.cs
===
--- System.Web.Compilation/CachingCompiler.cs (revision 61599)
+++ System.Web.Compilation/CachingCompiler.cs (working copy)
@@ -92,8 +92,7 @@
ICodeCompiler comp = compiler.Compiler;
results = comp.CompileAssemblyFromDom (compiler.CompilerParameters, compiler.Unit);
-string [] deps = (string []) compiler.Parser.Dependencies.ToArray (typeof (string));
-cache.InsertPrivate (key, results, new CacheDependency (deps));
+cache.InsertPrivate (key, results, new CacheDependency (compiler.Parser.GetLowerDependencies ()));
} finally {
Monitor.Exit (ticket);
if (acquired)
Index: System.Web.Compilation/AspGenerator.cs
===
--- System.Web.Compilation/AspGenerator.cs (revision 61599)
+++ System.Web.Compilation/AspGenerator.cs (working copy)
@@ -278,8 +278,7 @@
BaseCompiler compiler = GetCompilerFromType ();
type = compiler.GetCompiledType ();
- CacheDependency cd = new CacheDependency ((string[])
- tparser.Dependencies.ToArray (typeof (string)));
+ CacheDependency cd = new CacheDependency (tparser.GetLowerDependencies());
HttpRuntime.Cache.InsertPrivate (@@Type + tparser.InputFile, type, cd);
return type;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building steps for Visual Studio 2005 ?
Hi, I got mono from snv, and I read the README.vsnet, saying that there was some prerequisite to use mono under VS2005, but no details about it ( except that it needs monoburg and genmdesc ...). Before loading the project under VS2005, what do I have to do under cygwin ? make the whole project to generate some files, or just some modules ? Thanks in advance :) -- Try ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Timers.Timer bug
Hi, I found a multi-threading problem in implementation of System.Timers.Timer class. In our application we are using Timer.Enabled property inside of ElapsedEventHandler method to prevent timer from raising the Elapsed event again while previous handler is still running. In some cases Timer can be disabled and enabled again very fast. The problem under Mono is with member ManualResetEvent wait. In some cases new thread created by enabling Timer starts and creates instance of wait object before the old thread ends. Then the old thread dispose wait object and new thread throws unhandled NullRefrenceException. I'm attaching modified System.Timers.Timer class from Mono-1.1.15 sources with possible solution. Regards, Vojtech Jakubec Telco software development (VAS) STROM telecom, a.s. Tel.: +420211029 248 BB Cenrum Beta, Vyskočilova 1461/2a, 140 00 Praha 4, Czech Republic www.strom.cz DISCLAIMER This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Timer.cs Description: Timer.cs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building steps for Visual Studio 2005 ?
On Mon, 2006-06-12 at 15:10 +0200, Thibault Jochem wrote: Hi, I got mono from snv, and I read the README.vsnet, saying that there was some prerequisite to use mono under VS2005, but no details about it ( except that it needs monoburg and genmdesc ...). A working cygwin (http://www.cygwin.com/) setup! implied being able to build mono under cygwin. I'll update the document to make this clearer. Before loading the project under VS2005, what do I have to do under cygwin ? make the whole project to generate some files, or just some modules ? You must be able to build mono under cygwin before attempting to compile it with VS.NET. You may want to look at the list archive as some people have reduced this requirement. However you'll still need cygwin (and mono building on it) for other tasks (like building the class libraries, testing the runtime). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Single thread scheduler for Threading.Timers patch
At 11:04 PM 13/06/2006 -0700, Rafael Ferreira wrote: Howdy, The attached patch changes the current Threading.Timer class to use a single thread scheduler instead of the current 1 thread per timer logic. I also spent a lot of time working on the Timer unit tests so they more consistently pass as well as fixing the NotWorking tests. Some key features include: * A single thread handles firing all timer jobs thus allowing a much greater number of Timers to be defined - Fixing bug #65734 * Timer scheduler is only started after the first System.Threading.Timer is created (lazy init) * Timer scheduler thread dies if there are no more timer jobs in its Job queue (early termination) * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG environment variable One thing that gets me about the design is the way that timer events are marshalled to a different thread (in the thread pool) in order to be fired. Obviously, you don't want synchronous callbacks from a single thread for all timers, but perhaps a timer thread pool, each of which handling a subset of the timers, would be a viable alternate design. With a limit of, say, 100 scheduler threads, up to 100 timers could be created without any chance of interference, and after that point, the threads would be reused instead of overloading the system with thousands of threads. The threads could even switch from synchronous callbacks when they are handling only a single timer to asynchronous thread pool callbacks when their responsibilities increase. If we accept the single-thread thread-pool-callback design, though, I have the following comments on the implementation: 1. A heap structure is very easy to maintain, and would be a significantly more efficient way to find the next event to be fired. You have comments that acknowledge the deficiency of looping over the entire set every time, and I think this would be the logical next step in this. 2. Using Thread.Abort to signal the thread is fundamentally flawed. A user very quickly adding removing timers would eventually cause a ThreadAbortException to fire inside the 'catch' handler, killing off the scheduler thread and disabling all timers. A better approach would be to use Monitor.Wait on a synchronization object in the scheduler thread with the correct time-out, and then Monitor.Pulse to awaken the thread for an update. The scheduler can use DateTime.Now comparisons to determine, when Monitor.Wait returns, how long it actually waited and whether it should actually fire the event at top of the heap, and the return value of Monitor.Wait will indicate whether it was interrupted and thus should check the queue of timer additions/deletions before proceeding. If you'd like, I can try writing an alternate implementation along these lines, but it will have to wait until after work for me today. Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
I am confused: which is your true opinion? 1) OK, now I understan your problem. This is not an opinion. This is only a feedback that I have understood Miguel's problem he was speaking of. But I don't means that I have the same opinion. 2) It may be improper to assume that there is an internal method called InternalAllocateStr even more improper to assume that strings can be modified but I don't think that using reflection to access non-public members is improper. This is my opinion. And another important opinion is that if we assume that our class library assemblies have permission to use unsafe code and P/Invoke that are higher privileges we can assume that they have reflection permissions as well. If they hasn't got these permissions exceptions will be raised but this is true for unsafe code and P/Invoke as well. So if our opinion is that we should not depend on permissions we should not use either unsafe code or P/Invoke. And I think this is somethig we don't want. But if our opinion is that it's OK to require full trust or highly privileged permissions at least we can use reflection as well. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
Kornél Pál wrote: I am confused: which is your true opinion? 1) OK, now I understan your problem. This is not an opinion. This is only a feedback that I have understood Miguel's problem he was speaking of. But I don't means that I have the same opinion. 2) It may be improper to assume that there is an internal method called InternalAllocateStr even more improper to assume that strings can be modified but I don't think that using reflection to access non-public members is improper. This is my opinion. And another important opinion is that if we assume that our class library assemblies have permission to use unsafe code and P/Invoke that are higher privileges we can assume that they have reflection permissions as well. If they hasn't got these permissions exceptions will be raised but this is true for unsafe code and P/Invoke as well. So if our opinion is that we should not depend on permissions we should not use either unsafe code or P/Invoke. And I think this is somethig we don't want. But if our opinion is that it's OK to require full trust or highly privileged permissions at least we can use reflection as well. Then it is very hard to understand why you posted a revised patch that just removed reflection stuff. No one would think that you disagree with Miguel when he or she read that reply. Anyways it matches my understanding. Now we are ready to revert your changes depending on the future direction without extra discussion which might happen, as well as the possibility to add extra reflection dependency. I don't like such extra dependency though, since it makes code impossible to reuse or to try on other platforms than existing mono itself. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Version-specific binding - resolved, but real bugs found
Gonzalo Paniagua Javier wrote:
Can you please file bug reports in bugzilla.ximian.com and attach a test
case for these problems?
Turns out it's a false alarm on the second one. The properties on dynamic
assemblies in .NET also throw exceptions, though I still think this behavior is
bad design because it should be treated the same as if the assembly had been
loaded as a bag-o-bytes.
On the first one, I found that the reason my implicitly-loading assemblies were
not showing up is because the assemblies loaded into my first domain had
propogated into the second one. So the bug here is not that the correct assembly
wasn't being reported, it was that it wasn't even being loaded!
A quick example:
==
using System;
using System.Reflection;
namespace Test {
class TestClass {
public static void Main( string[] args ) {
AppDomain newDomain = AppDomain.CreateDomain( testDomain );
foreach( Assembly assem in newDomain.GetAssemblies() ) {
Console.WriteLine( assem.FullName );
}
}
}
}
==
Under .NET, this program reports the following assembly in the new AppDomain:
mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Under Mono, these assemblies are reported:
mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
test-EmptyAppDomain, Version=0.0.0.0, Culture=neutral
It can be shown that any assembly found in the AppDomain that called
CreateDomain ends up in the new domain.
This has been filed as bug #78648.
--Brian
using System;
using System.Reflection;
namespace Test {
class TestClass {
public static void Main( string[] args ) {
AppDomain newDomain = AppDomain.CreateDomain(
testDomain );
foreach( Assembly assem in newDomain.GetAssemblies() ) {
Console.WriteLine( assem.FullName );
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] (no subject)
Aloha. I realy need some help with the install Mono. I have run into a config issue. When I compile the mod_mono code, the configure works fine (see below). However, when I make it craps out complaining about some some code that is missing or not compatible. Do you have any thoughts to this? I am running suse 10.1. Configuration summary for mod_mono * Installation prefix = /usr * Apache version = 2.2 * Apache modules directory = /usr/lib/apache2 * apxs = /usr/sbin/apxs2 * apr-config = /usr/bin/apr-1-config * Verbose logging (debug) = no * mono prefix = /usr/lib/pkgconfig/../.. * Default MonoApplicationsConfigDir = /etc/apache2/mod-mono-applications Thanks so much, State of Hawaii Information Technology Service Office Brian Low 830 Punchbowl Street Room 216 Honolulu, HI 96813 E-mail: [EMAIL PROTECTED]___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
Hi, Anyways it matches my understanding. Now we are ready to revert your changes depending on the future direction without extra discussion which might happen, as well as the possibility to add extra reflection dependency. I don't like such extra dependency though, since it makes code impossible to reuse or to try on other platforms than existing mono itself. I have the same opinion regarding these things so I'm happy.:) And anyway I like to discuss things because I believe that discussing different opinions has good results. Note that I didn't committed any reflection related thinks so there is nothing to revert. I don't like late binding either (unless really necessary) but not because of CAS rather than because it causes no compilation error so makes the code more difficult to maintain and late binging is less efficient than compile-time linking. When I tried new string ((char) 0, length) I noticed that altough it's slower than InternalAllocateStr, when InternalAllocateStr is called using a late binding the performance gain is little so it's better to avoid reflection in this case. Note that I posted this patch but it was out of interest: http://lists.ximian.com/pipermail/mono-devel-list/2005-December/016253.html But there allways were different views: for example I was asked to impement functionality in corlib and use it from mcs using reflection: http://lists.ximian.com/pipermail/mono-devel-list/2006-March/017409.html (BTW I should repost the modified version of this patch at some time in the future.:) All solutions has advantages and drawbacks as well. I was debating about reflection becuase there should be some solution to the problem of internal interopability of the class library and/or compilers instead following different ways. Microsoft uses public methods then documents that This type/member supports the .NET Framework infrastructure and is not intended to be used directly from your code. - I think we should not follow this strategy. Other solution is to use reflection on non-public types/members that has the disadvantages we have discussed. Or use InternalsVisibleToAttribute that is not available in profile 1.x. - By hacking the runtime and mcs to allow this attribute type be declared in the assembly privately and serve the same purpose this problem could be solved however and this solution provides the best performance. You mentioned code reusing on other platforms. Regardless of the methods used when using non-standard or non-public members or types this is a problem. But for example the interaction between System.Windows.Forms and System.Drawing or between mono-service and System.ServiceProcess is required in order to be possible to implement their functionality so some solution should be preferred and used. Kornél - Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Wednesday, June 14, 2006 7:15 PM Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString() Kornél Pál wrote: I am confused: which is your true opinion? 1) OK, now I understan your problem. This is not an opinion. This is only a feedback that I have understood Miguel's problem he was speaking of. But I don't means that I have the same opinion. 2) It may be improper to assume that there is an internal method called InternalAllocateStr even more improper to assume that strings can be modified but I don't think that using reflection to access non-public members is improper. This is my opinion. And another important opinion is that if we assume that our class library assemblies have permission to use unsafe code and P/Invoke that are higher privileges we can assume that they have reflection permissions as well. If they hasn't got these permissions exceptions will be raised but this is true for unsafe code and P/Invoke as well. So if our opinion is that we should not depend on permissions we should not use either unsafe code or P/Invoke. And I think this is somethig we don't want. But if our opinion is that it's OK to require full trust or highly privileged permissions at least we can use reflection as well. Then it is very hard to understand why you posted a revised patch that just removed reflection stuff. No one would think that you disagree with Miguel when he or she read that reply. Anyways it matches my understanding. Now we are ready to revert your changes depending on the future direction without extra discussion which might happen, as well as the possibility to add extra reflection dependency. I don't like such extra dependency though, since it makes code impossible to reuse or to try on other platforms than existing mono itself. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Single thread scheduler for Threading.Timers patch
At 09:37 AM 14/06/2006 -0700, Rafael Ferreira wrote: Hey there, let me start by saying thanks for the feedback.. my commments below: No problem :-) By the way, it may have appeared to be off of the list (I mention this because I didn't see your reply on the list), but actually my post was to mono-devel-list and CCed to you. I've done the same with this reply; I hope that's okay with you :-) At 11:04 PM 13/06/2006 -0700, Rafael Ferreira wrote: Howdy, The attached patch changes the current Threading.Timer class to use a single thread scheduler instead of the current 1 thread per timer logic. I also spent a lot of time working on the Timer unit tests so they more consistently pass as well as fixing the NotWorking tests. Some key features include: * A single thread handles firing all timer jobs thus allowing a much greater number of Timers to be defined - Fixing bug #65734 * Timer scheduler is only started after the first System.Threading.Timer is created (lazy init) * Timer scheduler thread dies if there are no more timer jobs in its Job queue (early termination) * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG environment variable One thing that gets me about the design is the way that timer events are marshalled to a different thread (in the thread pool) in order to be fired. Obviously, you don't want synchronous callbacks from a single thread for all timers, but perhaps a timer thread pool, each of which handling a subset of the timers, would be a viable alternate design. With a limit of, say, 100 scheduler threads, up to 100 timers could be created without any chance of interference, and after that point, the threads would be reused instead of overloading the system with thousands of threads. The threads could even switch from synchronous callbacks when they are handling only a single timer to asynchronous thread pool callbacks when their responsibilities increase. I'm not sure what do you mean by marshalled to a different thread, there's no serialization taking place here and this implementation is not any different than what is currently being done by the timer class. The only difference is that I chose to call ThreadPool.QueueUserWorkItem explicitly instead of using .BeingInvoke(). Also, having n scheduler therads would not help you much, actually I the whole point of the single-thread scheduler is to minimize idle threads. The call to ThreadPool.QueueUserWorkItem *is* the marshalling I was referring to. It isn't data that's being marshalled, but rather the function call itself. The only concern I had was with the responsiveness of thread pool threads being awakened when they have possibly been asleep for a long time; if pages have to be brought into memory when the thread pool threads unblock, then the timer will have possibly several additional seconds of delay added to the callback. Obviously, making the callback from the thread that is driving the timer wouldn't have this problem, but it would have the different problem that if the callback takes too long the timer's activity (and that of any other timers on the same thread) will be negatively affected. I'm not actually sure how Microsoft's implementation works. I could write a couple of tests and run them. Specifically, what I'm interested to know is, if you have only one timer running, and that timer's callback takes longer than the interval, will the next timer tick cause another, re-entrant call into the callback on another thread, or does that next tick get delayed until the callback returns? The MSDN documentation makes it clear that thread pool threads are involved, but it doesn't indicate whether the thread pool threads themselves drive the timer, or whether the timer(s) are driven by a separate thread and only the callbacks are done through the thread pool. If we accept the single-thread thread-pool-callback design, though, I have the following comments on the implementation: 1. A heap structure is very easy to maintain, and would be a significantly more efficient way to find the next event to be fired. You have comments that acknowledge the deficiency of looping over the entire set every time, and I think this would be the logical next step in this. I agree that a sorted data structure would speed things up the problem there is that SortedList will just not cut it and writing a new data structure (or a wrapper class) just didn't sense just to speed up a very edge case (how many users are going create 10k timers?) Sure, but heaps are especially easy to write :-) They fit into an array, and they require only three helper methods to update the structure: swap, heapify-up and heapify-down. When a new timer is added, you simply drop it onto the end of the array, and then heapify-up. When a timer tick occurs, you move the item at the end of the array overtop of the one at the front of the array, and then heapify-down. Following these rules, the first entry in the array will always be the
[Mono-dev] ikvm source tarball
Hi, Should there be some source code in the ikvm tarball available from the go-mono/sources website? It's only got dlls and binaries in there. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu hüpfen signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [Fwd: databinder works?]
Thanks very much by the clue, But, can you tell me way a work around to it? text='%# DataBinder.Eval(DataSet,Tables[Clients].DefaultView.[0].Client) %' Thanks, Marco Castro Martin Hinks escreveu: If you read the first line of the exception it is fairly clear what the problem is: System.NotImplementedException: The requested feature is not implemented. Unfortunately this portion of Mono has not yet been completed and so is not implemented... yet. On 6/13/06, Marco Aurélio Castro [EMAIL PROTECTED] wrote: Hello, I'm developing a site in Delphi 2006 to run in Mono and I tried to connect a Dataset with an edit box by DataBinder. The connection is text='%# DataBinder.Eval(DataSet, Tables[Clients].DefaultView.[0].Client) %' It works in Windows, what is wrong here? -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12/6/2006 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
Hi Brian,Can you post the actual error you get when you run make?Cheers,Joejoe_audette [at] yahoo dotcom http://www.joeaudette.com http://www.mojoportal.com- Original Message From: [EMAIL PROTECTED]To: mono-devel-list@lists.ximian.comSent: Wednesday, June 14, 2006 2:18:07 PMSubject: [Mono-dev] (no subject)Aloha. I realy need some help with the install Mono. I have run into a config issue. When I compile the mod_mono code, the configure works fine (see below). However, when I make it craps out complaining about some some code that is missing or not compatible. Do you have any thoughts to this? I am running suse 10.1. Configuration summary for mod_mono * Installation prefix = /usr * Apache version = 2.2 * Apache modules directory = /usr/lib/apache2 * apxs = /usr/sbin/apxs2 * apr-config = /usr/bin/apr-1-config * Verbose logging (debug) = no * mono prefix = /usr/lib/pkgconfig/../.. * Default MonoApplicationsConfigDir = /etc/apache2/mod-mono-applications Thanks so much, State of Hawaii Information Technology Service Office Brian Low 830 Punchbowl Street Room 216 Honolulu, HI 96813 E-mail: [EMAIL PROTECTED]___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://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] [PATCH] System.Web.Compilation.TemplateControlCompiler
On Wed, 2006-06-14 at 06:37 -0700, Andrew Skiba wrote:
Hello,
Please review test and patch for TemplateControlCompiler. The bug was
that assignment statement was generated for a read-only property. If no
one objects, I will commit.
I don't think this patch is ok. And I'm tired of seeing that 'if no one
objects, I'll commit'. You should wait patiently until the patch is
approved and resubmit if you get no answer, which is what everyone else
does.
AddCodeForPropertyOrField can be called with a FieldInfo, and this will
make:
+ if (isDataBound ((PropertyInfo)
member).CanWrite) {
crash.
-Gonzalo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Version-specific binding - resolved, but real bugsfound
Hi, Actually it is only XSP (and mod-mono-server) that depends on this. And it could be solved by simply installing Mono.WebServer.dll to the GAC but this is what Mono team don't want to do because the API of Mono.WebServer.dll is not stable and the conception of GAC is to have assemblies with stable API. Another solution could be to construct the AppDomain inside Mono.WebServer.dll (or use a non-public method in System.Web.dll) that uses AppDomain.CreateInstanceFrom so Mono.WebServer.dll would be loaded without problems if it's not installed to the GAC. But they don't want to do this because this could make XSP incompatible with other runtimes. (Altough it isn't compatible with other runtimes because it relies on this bug...) But the of modifying (or keeping) the runtime to behave incorrectly sounds to me as a nonsense. And the official point of view of Mono team is to use this solution because they consider the other solutions being less compatible with MS.NET or being more improper than this one. But the truth is that this is the most improper solution and breaking a lot of applications just for XSP is not worth... As I see this situation they take this bug too personally and they don't see what is good for Mono. Kornél - Original Message - From: Brian Crowell [EMAIL PROTECTED] To: Jb Evain [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Wednesday, June 14, 2006 11:52 PM Subject: Re: [Mono-dev] Version-specific binding - resolved, but real bugsfound Jb Evain wrote: This is discussed here: http://bugzilla.ximian.com/show_bug.cgi?id=76757 Ah, good. I thought I was alone here. So, from that discussion I gather that this is a known bug that no-one wants to fix, for fear of having to fix other applications that rely on it. And yet, from my perspective, this is a known bug that prevents my application from running, since my app relies on being able to load two different versions of the same assembly in two different AppDomains. Is that where we stand? Because I would certainly be willing to fix the bug in the runtime, and, regardless, it must be fixed, though I would really appreciate your input on how to do it. --Brian ___ 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
[Mono-dev] Mono on the x86 Intel Macs
Is there any projected time line on when an Intel Mono installer will be available for the Intel Macs? If not, are there any notes some where on how to properly build mono for the Intels? Thanks! - [EMAIL PROTECTED] is a NetIBA validated email address. Certificate #604044E. Protect yourself against Internet fraud by getting the Consumer Protection Tool at www.netiba.com/?2764. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on the x86 Intel Macs
The plan is to have one out the next couple of weeks. Wade On Wed, 2006-06-14 at 18:40 -0500, Colt D. Majkrzak wrote: Is there any projected time line on when an Intel Mono installer will be available for the Intel Mac’s? If not, are there any notes some where on how to properly build mono for the Intel’s? Thanks! - [EMAIL PROTECTED] is a NetIBA validated email address. Certificate #604044E. Protect yourself against Internet fraud by getting the Consumer Protection Tool at www.netiba.com/?2764. ___ 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
