Search Results

Search found 60 results on 3 pages for 'queueuserworkitem'.

Page 1/3 | 1 2 3  | Next Page >

  • C# ThreadPool QueueUserWorkItem Synchronization

    - by ikurtz
    Greetings, I am employing ThreadPool.QueueUserWorkItem to play some sound files and not hanging up the GUI while doing so. It is working but has an undesirable side effect. While the QueueUserWorkItem CallBack Proc is being executed there is nothing to stop it from starting a new thread. This causes the samples in the threads to overlap. How can I make it so that it waits for the already running thread to finish running and only then run the next request? Thanks in advance :)

    Read the article

  • C# multi CPU for ThreadPool.QueueUserWorkItem

    - by ikurtz
    I have a program that uses: ThreadPool.QueueUserWorkItem(new WaitCallback(FireAttackProc), fireResult); On Windows7 and Vista it works fine. When I try to run it on XP the result is a bit different from the others. I was just wondering in order to execute QueueUserWorkItem properly do I need a dual CPU system? The XP I tried to test on had .Net 3.5 installed. Inputs most welcome.

    Read the article

  • Is this a good use for ThreadPool.QueueUserWorkItem?

    - by Matt Grande
    I have an application that, among other things, imports documents, then emails necessary parties to let them know that a document has been imported. It turns out that determining whom to email, then performing the emailing, is what's taking the longest. I was thinking of doing something like this: var document = ImportDocument(); ThreadPool.QueueUserWorkItem(s => SendEmail(document.Id)); return document; ... similar to DelayedJob in Rails, if that helps. Does that make sense in this context? What would you do?

    Read the article

  • TaskFactory.StartNew versus ThreadPool.QueueUserWorkItem

    - by Dan Tao
    Apparently the TaskFactory.StartNew method in .NET 4.0 is intended as a replacement for ThreadPool.QueueUserWorkItem (according to this post, anyway). My question is simple: does anyone know why? Does TaskFactory.StartNew have better performance? Does it use less memory? Or is it mainly for the additional functionality provided by the Task class? In the latter case, does StartNew possibly have worse performance than QueueUserWorkItem? It seems to me that StartNew would actually potentially use more memory than QueueUserWorkItem, since it returns a Task object with every call and I would expect that to result in more memory allocation. In any case, I'm interested to know which is more appropriate for a high-performance scenario.

    Read the article

  • .NET ThreadPool QueueUserWorkItem Synchronization

    - by ikurtz
    I am employing ThreadPool.QueueUserWorkItem to play some sound files and not hanging up the GUI while doing so. It is working but has an undesirable side effect. While the QueueUserWorkItem CallBack Proc is being executed there is nothing to stop it from starting a new thread. This causes the samples in the threads to overlap. How can I make it so that it waits for the already running thread to finish running and only then run the next request? EDIT: I did: Thread t = new Thread(FireAttackProc(fireResult)); t.Start(); but it gave me some errors. How do I specify a thread method with parameters?

    Read the article

  • Using ThreadPool.QueueUserWorkItem - thread unexpectedly exits

    - by alex
    I have the following method: public void PutFile(string ID, Stream content) { try { ThreadPool.QueueUserWorkItem(o => putFileWorker(ID, content)); } catch (Exception ex) { OnPutFileError(this, new ExceptionEventArgs { Exception = ex }); } } The putFileWorker method looks like this: private void putFileWorker(string ID, Stream content) { //Get bucket name: var bucketName = getBucketName(ID) .ToLower(); //get file key var fileKey = getFileKey(ID); try { //if the bucket doesn't exist, create it if (!Amazon.S3.Util.AmazonS3Util.DoesS3BucketExist(bucketName, s3client)) s3client.PutBucket(new PutBucketRequest { BucketName = bucketName, BucketRegion = S3Region.EU }); PutObjectRequest request = new PutObjectRequest(); request.WithBucketName(bucketName) .WithKey(fileKey) .WithInputStream(content); S3Response response = s3client.PutObject(request); var xx = response.Headers; OnPutFileCompleted(this, new ValueEventArgs { Value = ID }); } catch (Exception e) { OnPutFileError(this, new ExceptionEventArgs { Exception = e }); } } I've created a little console app to test this. I wire up event handlers for the OnPutFileError and OnPutFileCompleted events. If I call my PutFile method, and step into this, it gets to the "//if the bucket doesn't exist, create it" line, then exits. No exception, no errors, nothing. It doesn't complete (i've set breakpoints on my event handlers too) - it just exits. If I run the same method without the ThreadPool.QueueUserWorkItem then it runs fine... Am I missing something?

    Read the article

  • Advantage of using Thread.Start vs QueueUserWorkItem

    - by Cheeso
    In multithreaded .NET programming, what are the decision criteria for using ThreadPool.QueueUserWorkItem versus starting my own thread via new Thread() and Thread.Start()? In a server app (let's say, an ASP.NET app or a WCF service) I think the ThreadPool is always there and available. What about in a client app, like a WinForms or WPF app? Is there a cost to spin up the thread pool? If I just want 3 or 4 threads to work for a short period on some computation, is it better to QUWI or to Thread.Start().

    Read the article

  • ThreadPool.QueueUserWorkItem new Form CreateHandle Deadlock

    - by bogdanbrudiu
    I have a thread that needs to create a popup Window. I start the thread using ThreadPool.QueueUserWorkItem(new WaitCallback(CreatePopupinThread)) Thew thread creats a new form. The application freases in the new Form constructor at CreateHandle. The Worker Thread is locked... How can I fix this? this is how I create the form var form = new ConfirmationForm { Text = entry.Caption, Label = entry.Text, }; In the constructor the thread enters a deadlock public ConfirmationForm() { InitializeComponent(); }

    Read the article

  • ThreadStateException when using QueueUserWorkItem in a Timer

    - by Tim
    Hi all, I have a ThreadStateException in my winforms application. Step to reproduce : Create simple winforms app Add a button In click event, do : timer1.Interval = 1000; timer1.Tick += timer1_Tick; timer1.Start(); void timer1_Tick(object sender, EventArgs e) { ThreadPool.QueueUserWorkItem(delegate { StringCollection paths = new StringCollection { @"c:\my.txt", @"c:\my.png" }; Clipboard.SetFileDropList(paths); }); } The exception tells me : Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it. But the main has already the [STAThread] attribute. How to solve it ? Thanks in advance for any help

    Read the article

  • Using ThreadPool.QueueUserWorkItem in ASP.NET in a high traffic scenario

    - by Michael Hart
    I've always been under the impression that using the ThreadPool for (let's say non-critical) short-lived background tasks was considered best practice, even in ASP.NET, but then I came across this article that seems to suggest otherwise - the argument being that you should leave the ThreadPool to deal with ASP.NET related requests. So here's how I've been doing small asynchronous tasks so far: ThreadPool.QueueUserWorkItem(s => PostLog(logEvent)) And the article is suggesting instead to create a thread explicitly, similar to: new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start() The first method has the advantage of being managed and bounded, but there's the potential (if the article is correct) that the background tasks are then vying for threads with ASP.NET request-handlers. The second method frees up the ThreadPool, but at the cost of being unbounded and thus potentially using up too many resources. So my question is, is the advice in the article correct? If your site was getting so much traffic that your ThreadPool was getting full, then is it better to go out-of-band, or would a full ThreadPool imply that you're getting to the limit of your resources anyway, in which case you shouldn't be trying to start your own threads? Clarification: I'm just asking in the scope of small non-critical asynchronous tasks (eg, remote logging), not expensive work items that would require a separate process (in these cases I agree you'll need a more robust solution).

    Read the article

  • C# Thread Queue Synchronize

    - by ikurtz
    Greetings, I am trying to play some audio files without holding up the GUI. Below is a sample of the code: if (audio) { if (ThreadPool.QueueUserWorkItem(new WaitCallback(CoordinateProc), fireResult)) { } else { MessageBox.Show("false"); } } if (audio) { if (ThreadPool.QueueUserWorkItem(new WaitCallback(FireProc), fireResult)) { } else { MessageBox.Show("false"); } } if (audio) { if (ThreadPool.QueueUserWorkItem(new WaitCallback(HitProc), fireResult)) { } else { MessageBox.Show("false"); } } The situation is the samples are not being played in order. some play before the other and I need to fix this so the samples are played one after another in order. How do I implement this please? Thank you.

    Read the article

  • Terminate long running thread in thread pool that was created using QueueUserWorkItem(win 32/nt5).

    - by Jake
    I am programming in a win32 nt5 environment. I have a function that is going to be called many times. Each call is atomic. I would like to use QueueUserWorkItem to take advantage of multicore processors. The problem I am having is I only want to give the function 3 seconds to complete. If it has not completed in 3 seconds I want to terminate the thread. Currently I am doing something like this: HANDLE newThreadFuncCall= CreateThread(NULL,0,funcCall,&func_params,0,NULL); DWORD result = WaitForSingleObject(newThreadFuncCall, 3000); if(result == WAIT_TIMEOUT) { TerminateThread(newThreadFuncCall,WAIT_TIMEOUT); } I just spawn a single thread and wait for 3 seconds or it to complete. Is there anyway to do something similar to but using QueueUserWorkItem to queue up the work? Thanks!

    Read the article

  • ASP.NET Exception Handling in background threads

    - by Xodarap
    When I do ThreadPool.QueueUserWorkItem, I don't want unhandled exceptions to kill my entire process. So I do something like: ThreadPool.QueueUserWorkItem(delegate() { try { FunctionIActuallyWantToCall(); } catch { HandleException(); } }); Is this the recommended pattern? It seems like there should be a simpler way to do this. It's in an asp.net-mvc app, if that's relevant.

    Read the article

  • Multithreading in Windows Phone 7 emulator: A bug

    - by Laurent Bugnion
    Multithreading is supported in Windows Phone 7 Silverlight applications, however the emulator has a bug (which I discovered and was confirmed to me by the dev lead of the emulator team): If you attempt to start a background thread in the MainPage constructor, the thread never starts. The reason is a problem with the emulator UI thread which doesn’t leave any time to the background thread to start. Thankfully there is a workaround (see code below). Also, the bug should be corrected in a future release, so it’s not a big deal, even though it is really confusing when you try to understand why the *%&^$£% thread is not &$%&%$£ starting (that was me in the plane the other day ;) This code does not work: public partial class MainPage : PhoneApplicationPage { public MainPage() { InitializeComponent(); SupportedOrientations = SupportedPageOrientation.Portrait | SupportedPageOrientation.Landscape; var counter = 0; ThreadPool.QueueUserWorkItem(o => { while (true) { Dispatcher.BeginInvoke(() => { textBlockListTitle.Text = (counter++).ToString(); }); } }); } } This code does work: public MainPage() { InitializeComponent(); SupportedOrientations = SupportedPageOrientation.Portrait | SupportedPageOrientation.Landscape; var counter = 0; ThreadPool.QueueUserWorkItem(o => { while (true) { Dispatcher.BeginInvoke(() => { textBlockListTitle.Text = (counter++).ToString(); }); // NOTICE THIS LINE!!! Thread.Sleep(0); } }); } Note that even if the thread is started in a later event (for example Click of a Button), the behavior without the Thread.Sleep(0) is not good in the emulator. As of now, i would recommend always sleeping when starting a new thread. Happy coding: Laurent   Laurent Bugnion (GalaSoft) Subscribe | Twitter | Facebook | Flickr | LinkedIn

    Read the article

  • Parallelism in .NET – Part 16, Creating Tasks via a TaskFactory

    - by Reed
    The Task class in the Task Parallel Library supplies a large set of features.  However, when creating the task, and assigning it to a TaskScheduler, and starting the Task, there are quite a few steps involved.  This gets even more cumbersome when multiple tasks are involved.  Each task must be constructed, duplicating any options required, then started individually, potentially on a specific scheduler.  At first glance, this makes the new Task class seem like more work than ThreadPool.QueueUserWorkItem in .NET 3.5. In order to simplify this process, and make Tasks simple to use in simple cases, without sacrificing their power and flexibility, the Task Parallel Library added a new class: TaskFactory. The TaskFactory class is intended to “Provide support for creating and scheduling Task objects.”  Its entire purpose is to simplify development when working with Task instances.  The Task class provides access to the default TaskFactory via the Task.Factory static property.  By default, TaskFactory uses the default TaskScheduler to schedule tasks on a ThreadPool thread.  By using Task.Factory, we can automatically create and start a task in a single “fire and forget” manner, similar to how we did with ThreadPool.QueueUserWorkItem: Task.Factory.StartNew(() => this.ExecuteBackgroundWork(myData) ); .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } This provides us with the same level of simplicity we had with ThreadPool.QueueUserWorkItem, but even more power.  For example, we can now easily wait on the task: // Start our task on a background thread var task = Task.Factory.StartNew(() => this.ExecuteBackgroundWork(myData) ); // Do other work on the main thread, // while the task above executes in the background this.ExecuteWorkSynchronously(); // Wait for the background task to finish task.Wait(); TaskFactory simplifies creation and startup of simple background tasks dramatically. In addition to using the default TaskFactory, it’s often useful to construct a custom TaskFactory.  The TaskFactory class includes an entire set of constructors which allow you to specify the default configuration for every Task instance created by that factory.  This is particularly useful when using a custom TaskScheduler.  For example, look at the sample code for starting a task on the UI thread in Part 15: // Given the following, constructed on the UI thread // TaskScheduler uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); // When inside a background task, we can do string status = GetUpdatedStatus(); (new Task(() => { statusLabel.Text = status; })) .Start(uiScheduler); This is actually quite a bit more complicated than necessary.  When we create the uiScheduler instance, we can use that to construct a TaskFactory that will automatically schedule tasks on the UI thread.  To do that, we’d create the following on our main thread, prior to constructing our background tasks: // Construct a task scheduler from the current SynchronizationContext (UI thread) var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); // Construct a new TaskFactory using our UI scheduler var uiTaskFactory = new TaskFactory(uiScheduler); If we do this, when we’re on a background thread, we can use this new TaskFactory to marshal a Task back onto the UI thread.  Our previous code simplifies to: // When inside a background task, we can do string status = GetUpdatedStatus(); // Update our UI uiTaskFactory.StartNew( () => statusLabel.Text = status); Notice how much simpler this becomes!  By taking advantage of the convenience provided by a custom TaskFactory, we can now marshal to set data on the UI thread in a single, clear line of code!

    Read the article

  • C# threading pattern that will let me flush

    - by Jeff Alexander
    I have a class that implements the Begin/End Invocation pattern where I initially used ThreadPool.QueueUserWorkItem() to do thread my work. I now have the side effect where someone using my class is calling the Begin (with callback) a ton of times to do a lot of processing so ThreadPool.QueueUserWorkItem is creating a ton of threads to do the processing. That in itself isn't bad but there are instances where they want to abandon the processing and start a new process but they are forced to wait for their first request to finish. Since ThreadPool.QueueUseWorkItem() doesn't allow me to cancel the threads I am trying to come up with a better way to queue up the work and maybe use an explicit FlushQueue() method in my class to allow the caller to abandon work in my queue. Anyone have any suggestion on a threading pattern that fits my needs?

    Read the article

  • TcpListener is queuing connections faster than I can clear them

    - by Matthew Brindley
    As I understand it, TcpListener will queue connections once you call Start(). Each time you call AcceptTcpClient (or BeginAcceptTcpClient), it will dequeue one item from the queue. If we load test our TcpListener app by sending 1,000 connections to it at once, the queue builds far faster than we can clear it, leading (eventually) to timeouts from the client because it didn't get a response because its connection was still in the queue. However, the server doesn't appear to be under much pressure, our app isn't consuming much CPU time and the other monitored resources on the machine aren't breaking a sweat. It feels like we're not running efficiently enough right now. We're calling BeginAcceptTcpListener and then immediately handing over to a ThreadPool thread to actually do the work, then calling BeginAcceptTcpClient again. The work involved doesn't seem to put any pressure on the machine, it's basically just a 3 second sleep followed by a dictionary lookup and then a 100 byte write to the TcpClient's stream. Here's the TcpListener code we're using: // Thread signal. private static ManualResetEvent tcpClientConnected = new ManualResetEvent(false); public void DoBeginAcceptTcpClient(TcpListener listener) { // Set the event to nonsignaled state. tcpClientConnected.Reset(); listener.BeginAcceptTcpClient( new AsyncCallback(DoAcceptTcpClientCallback), listener); // Wait for signal tcpClientConnected.WaitOne(); } public void DoAcceptTcpClientCallback(IAsyncResult ar) { // Get the listener that handles the client request, and the TcpClient TcpListener listener = (TcpListener)ar.AsyncState; TcpClient client = listener.EndAcceptTcpClient(ar); if (inProduction) ThreadPool.QueueUserWorkItem(state => HandleTcpRequest(client, serverCertificate)); // With SSL else ThreadPool.QueueUserWorkItem(state => HandleTcpRequest(client)); // Without SSL // Signal the calling thread to continue. tcpClientConnected.Set(); } public void Start() { currentHandledRequests = 0; tcpListener = new TcpListener(IPAddress.Any, 10000); try { tcpListener.Start(); while (true) DoBeginAcceptTcpClient(tcpListener); } catch (SocketException) { // The TcpListener is shutting down, exit gracefully CheckBuffer(); return; } } I'm assuming the answer will be related to using Sockets instead of TcpListener, or at least using TcpListener.AcceptSocket, but I wondered how we'd go about doing that? One idea we had was to call AcceptTcpClient and immediately Enqueue the TcpClient into one of multiple Queue<TcpClient> objects. That way, we could poll those queues on separate threads (one queue per thread), without running into monitors that might block the thread while waiting for other Dequeue operations. Each queue thread could then use ThreadPool.QueueUserWorkItem to have the work done in a ThreadPool thread and then move onto dequeuing the next TcpClient in its queue. Would you recommend this approach, or is our problem that we're using TcpListener and no amount of rapid dequeueing is going to fix that?

    Read the article

  • Raise event from http listener (Async listener handler)

    - by Sean
    Hello, I have created an simple web server, leveraging .NET HttpListener class. I am using ThreadPool.QueueUserWorkItem() to spawn a thread to listen to incoming requests. Threaded method uses HttpListener.BeginGetContext(callback, listener), and in callback method I resume with HttpListener.EndGetContext() as well as raise an even to notify UI that listener received data. This is the question - how to raise that event? Initially I used ThreadPool: ThreadPool.QueueUserWorkItem(state => ReceivedRequest(httpListenerContext, receivedRequestArgs)); But then started to doubt, maybe it should be a dedicated thread (as appose to waiting for a thread from pool): new Thread(() => ReceivedRequest(httpListenerContext, receivedRequestArgs)).Start(); Thoughts? 10X

    Read the article

  • .NET socket timeout - blocking on Close method

    - by Mark
    I'm having trouble implementing a connect timeout using asynchronous socket calls. The idea being that I call BeginConnect on a Socket object, then use a timer to call Close() on the socket after a timeout period has elapsed. This works fine as long as the socket is created on the GUI thread - the Close method returns immediately, and the callback method is executed. However, if the socket is created on any other thread, the Close method blocks until the default IP timeout occurs. Code to reproduce: private Socket client; private void button1_Click(object sender, EventArgs e) { // Creating the socket on a threadpool thread causes Close to block. ThreadPool.QueueUserWorkItem((object state) => { client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); IAsyncResult result = client.BeginConnect(IPAddress.Parse("144.1.1.1"), 23, new AsyncCallback(CallbackMethod), client); // Wait for 2 seconds before closing the socket. if (result.AsyncWaitHandle.WaitOne(2000)) { MessageBox.Show("Connected."); } else { MessageBox.Show("Timed out. Closing socket..."); client.Close(); MessageBox.Show("Socket closed."); } }); } private void CallbackMethod(IAsyncResult result) { MessageBox.Show("Callback started."); Socket client = result.AsyncState as Socket; try { client.EndConnect(result); } catch (ObjectDisposedException) { } MessageBox.Show("Callback finished."); } If you remove the QueueUserWorkItem line, creating the socket on the GUI thread, the socket closes instantly without blocking. Can anyone shed some light on what's going on? Thanks. Edit - System.Net trace output seems to be different depending on whether it's being connected on the GUI thread or a different thread: Trace from non-blocking close when using GUI thread Trace from blocking close when using non-GUI thread

    Read the article

  • Seeking help with a MT design pattern

    - by SamG
    I have a queue of 1000 work items and a n-proc machine (assume n = 4).The main thread spawns n (=4) worker threads at a time ( 25 outer iterations) and waits for all threads to complete before processing the next n (=4) items until the entire queue is processed for(i= 0 to queue.Length / numprocs) for(j= 0 to numprocs) { CreateThread(WorkerThread,WorkItem) } WaitForMultipleObjects(threadHandle[]) The work done by each (worker) thread is not homogeneous.Therefore in 1 batch (of n) if thread 1 spends 1000 s doing work and rest of the 3 threads only 1 s , above design is inefficient,becaue after 1 sec other 3 processors are idling. Besides there is no pooling - 1000 distinct threads are being created How do I use the NT thread pool (I am not familiar enough- hence the long winded question) and QueueUserWorkitem to achieve the above. The following constraints should hold The main thread requires that all worker items are processed before it can proceed.So I would think that a waitall like construct above is required I want to create as many threads as processors (ie not 1000 threads at a time) Also I dont want to create 1000 distinct events, pass to the worker thread, and wait on all events using the QueueUserWorkitem API or otherwise Exisitng code is in C++.Prefer C++ because I dont know c# I suspect that the above is a very common pattern and was looking for input from you folks.

    Read the article

  • Multi-threaded library calls in ASP.NET page request.

    - by ProfK
    I have an ASP.NET app, very basic, but right now too much code to post if we're lucky and I don't have to. We have a class called ReportGenerator. On a button click, method GenerateReports is called. It makes an async call to InternalGenerateReports using ThreadPool.QueueUserWorkItem and returns, ending the ASP.NET response. It doesn't provide any completion callback or anything. InternalGenerateReports creates and maintains five threads in the threadpool, one report per thread, also using QueueUserWorkItem, by 'creating' five threads, also with and waiting until calls on all of them complete, in a loop. Each thread uses an ASP.NET ReportViewer control to render a report to HTML. That is, for 200 reports, InternalGenerateReports should create 5 threads 40 times. As threads complete, report data is queued, and when all five have completed, report data is flushed to disk. My biggest problems are that after running for just one report, the aspnet process is 'hung', and also that at around 200 reports, the app just hangs. I just simplified this code to run in a single thread, and this works fine. Before we get into details like my code, is there anything obvious in the above scendario that might be wrong?

    Read the article

  • Workaround for the WaitHandle.WaitAll 64 handle limit?

    - by James
    My application spawns loads of different small worker threads via ThreadPool.QueueUserWorkItem. I have never had any issues before, however, as my application is coming under more load i.e. more threads being created, I am now beginning to get this exception: WaitHandles must be less than or equal to 64 - missing documentation What is the best alternative solution to this?

    Read the article

  • Wait until all threads teminated in ThreadPool

    - by Neir0
    Hi i have this code: var list = new List<int>(); for(int i=0;i<10;i++) list.Add(i); for(int i=0;i<10;i++) { ThreadPool.QueueUserWorkItem( new WaitCallback(x => { Console.WriteLine(x); }),list[i]); } And i want to know when all threadpools threads finished their work. How i can to do that?

    Read the article

  • .NET JIT Code Cache leaking?

    - by pitchfork
    We have a server component written in .Net 3.5. It runs as service on a Windows Server 2008 Standard Edition. It works great but after some time (days) we notice massive slowdowns and an increased working set. We expected some kind of memory leak and used WinDBG/SOS to analyze dumps of the process. Unfortunately the GC Heap doesn’t show any leak but we noticed that the JIT code heap has grown from 8MB after the start to more than 1GB after a few days. We don’t use any dynamic code generation techniques by our own. We use Linq2SQL which is known for dynamic code generation but we don’t know if it can cause such a problem. The main question is if there is any technique to analyze the dump and check where all this Host Code Heap blocks that are shown in the WinDBG dumps come from? [Update] In the mean time we did some more analysis and had Linq2SQL as probable suspect, especially since we do not use precompiled queries. The following example program creates exactly the same behaviour where more and more Host Code Heap blocks are created over time. using System; using System.Linq; using System.Threading; namespace LinqStressTest { class Program { static void Main(string[] args) { for (int i = 0; i < 100; ++ i) ThreadPool.QueueUserWorkItem(Worker); while(runs < 1000000) { Thread.Sleep(5000); } } static void Worker(object state) { for (int i = 0; i < 50; ++i) { using (var ctx = new DataClasses1DataContext()) { long id = rnd.Next(); var x = ctx.AccountNucleusInfos.Where(an => an.Account.SimPlayers.First().Id == id).SingleOrDefault(); } } var localruns = Interlocked.Add(ref runs, 1); System.Console.WriteLine("Action: " + localruns); ThreadPool.QueueUserWorkItem(Worker); } static Random rnd = new Random(); static long runs = 0; } } When we replace the Linq query with a precompiled one, the problem seems to disappear.

    Read the article

1 2 3  | Next Page >