locked
file stream opened in a thread RRS feed

  • Question

  • Hi to all

    I need some advices for the next scenario: I have a simple app that spawns a thread and tries after that to write into a file (in a loop). The thread makes a streamReader on the same file and finishes its job after a few seconds without closing the stream. The big problem is that I am unable in the app to write into that file, even after the thread finished its job (and died). Is there any way to dispose that streamReader object (that should not exist anymore, because the thread died)? Thanks.

    Tuesday, January 17, 2012 1:58 PM

Answers

  • I understand what you mean, but the scenario is that I don't have access to those plugins.


    Since you don't have access to the plugins, how would you know that the plugin code is finished using the file and has released references to it? The plugin may still be using the file.

    If you're willing to host customers code, and they give you code which attacks your system, and you run it, that sounds like something which needs to be solved with business requirements, not code.

    I don't know exactly why you would host customer plugins, but something you could do is have each different customer plugin live in it's own AppDomain. You could configure IIS to host each one seperatly, and give each instance limited resources/permissions. Then if you detect its misbehaving, kill it. If, on the other hand, all of the plugins must be running in the same AppDomain, and have admin permissions on the server, I think the only thing you could there is force the customer to hand over the source code for each plugin, and you inspect to make sure it isn't going to do anything bad.

    • Proposed as answer by Paul Zhou Wednesday, January 25, 2012 6:18 AM
    • Marked as answer by eidrian88 Wednesday, January 25, 2012 9:12 AM
    Thursday, January 19, 2012 3:27 PM
  • It's all about security here. If somebody wants to do damage in such a service, how can I stop him?

    You can force the customers to implement some general abstract class for plugins that way you have some kind of an control, but generally permission and other security measures can prevent your bad behaving plugins do major damage. Infinite loop in plugin that halts my application is not the biggest problem when I've created applications that uses plugins, you pretty soon find that kind of an error and can get rid of the plugin for good. I've be more concerned about business related errors when implementing plugin framework.
    • Proposed as answer by Paul Zhou Wednesday, January 25, 2012 6:18 AM
    • Marked as answer by eidrian88 Wednesday, January 25, 2012 9:12 AM
    Thursday, January 19, 2012 1:42 PM

All replies

  • Dispose it the same way you disposed the StreamWriter.  Writers and Readers are typically enclosed in using blocks.
    Tuesday, January 17, 2012 3:12 PM
  • If thread is dead and the streamReader was created inside that thread, how should I disposed it from the main thread?

    Tuesday, January 17, 2012 4:12 PM
  • If thread is dead and the streamReader was created inside that thread, how should I disposed it from the main thread?


    You shouldn''t.  Too late.  How did you dispose the Writer from the main thread?
    Tuesday, January 17, 2012 4:16 PM
  • As a simple example, in the main thread I use File.AppendAllText. I reffer, of course, to a scalable application, in which I load some plugins in worker threads, threads that have a timeout to execute their job. Those plugins can access shared data and can have some loops to retry when failed. But what if a thread reaches the timeout, the main thread kills it, but streams are still open on certain files? Nobody can access those files until I restart the entire application?
    Wednesday, January 18, 2012 9:41 AM
  • " the main thread kills it"

    This shouldn't happen.  The main thread requests that the thread cancels and the thread exits gracefully. 

    Wednesday, January 18, 2012 9:55 AM
  • Think about a service which loads customer plugins in worker threads. What happens if that service loads a few plugins that have infinitive loops inside?
    Wednesday, January 18, 2012 10:23 AM
  • Hi,

    Before writing file steam check if the streamReader  is open or not if open forceble close and write into file .

     


    Regards, Looser.
    Wednesday, January 18, 2012 11:16 AM
  • The streamReader object is created inside the worker thread, so I don't have any reference to it form the main thread...that's the scenario. Thanks
    Wednesday, January 18, 2012 11:18 AM
  • Think about a service which loads customer plugins in worker threads. What happens if that service loads a few plugins that have infinitive loops inside?

    Advise your customers to rewrite their plugins.  We can go on like this forever.  If you forcefully abort threads, you must accecpt the consequences, which will frequently require a restart of the app.

    Wednesday, January 18, 2012 11:56 AM
  • It's all about security here. If somebody wants to do damage in such a service, how can I stop him?
    Wednesday, January 18, 2012 1:31 PM
  • Also it's hard for me to understand why the CLR doesn't clear the streamReader if it's not reffered anymore :)
    Wednesday, January 18, 2012 1:33 PM
  • Also it's hard for me to understand why the CLR doesn't clear the streamReader if it's not reffered anymore :)


    It's an optimization to save time. While the garbage collector is running in the background, it's not constantly doing actual collection in the background. The garbage collector will do mark and sweep passes for all of the objects periodically (based off of how frequently objects are being allocated, and sometimes due to memory pressure). Once the GC finds that an object isn't being referred to anymore (and this can be way after its stopped being referred to) and that object has a finalizer, the object gets placed in the finalizer queue. The finalizer thread will run periodically and call the finalizer on all of the objects in the queue. It's possible for a poorly written object to hang in it's finalizer method and block the finalizer thread from emptying any more objects from the queue.

    If the Garbage Collector was constantly and immediatly finalizing and free up objects, it would be too much of an overhead, and no one would write managed code.

    The answer to your original question of how to clean up the filestream object is to call GC.Collect() and then GC.WaitForPendingFinalizers(). Is this what you're supposed to do? No. Will it work? Yes. What should you do? You're supposed to dispose of non-memory resources (ie. a file handle) once you're done using them.

    Wednesday, January 18, 2012 11:50 PM
  • I understand what you mean, but the scenario is that I don't have access to those plugins. They're written by customers, let's say. I think to possible situations that could crash the service (or deny it) or even the server. Also, the test I've did was a simple console app, and even after 10-15 minutes the file lock was still in place.
    Thursday, January 19, 2012 8:30 AM
  • It's all about security here. If somebody wants to do damage in such a service, how can I stop him?

    You can force the customers to implement some general abstract class for plugins that way you have some kind of an control, but generally permission and other security measures can prevent your bad behaving plugins do major damage. Infinite loop in plugin that halts my application is not the biggest problem when I've created applications that uses plugins, you pretty soon find that kind of an error and can get rid of the plugin for good. I've be more concerned about business related errors when implementing plugin framework.
    • Proposed as answer by Paul Zhou Wednesday, January 25, 2012 6:18 AM
    • Marked as answer by eidrian88 Wednesday, January 25, 2012 9:12 AM
    Thursday, January 19, 2012 1:42 PM
  • I understand what you mean, but the scenario is that I don't have access to those plugins.


    Since you don't have access to the plugins, how would you know that the plugin code is finished using the file and has released references to it? The plugin may still be using the file.

    If you're willing to host customers code, and they give you code which attacks your system, and you run it, that sounds like something which needs to be solved with business requirements, not code.

    I don't know exactly why you would host customer plugins, but something you could do is have each different customer plugin live in it's own AppDomain. You could configure IIS to host each one seperatly, and give each instance limited resources/permissions. Then if you detect its misbehaving, kill it. If, on the other hand, all of the plugins must be running in the same AppDomain, and have admin permissions on the server, I think the only thing you could there is force the customer to hand over the source code for each plugin, and you inspect to make sure it isn't going to do anything bad.

    • Proposed as answer by Paul Zhou Wednesday, January 25, 2012 6:18 AM
    • Marked as answer by eidrian88 Wednesday, January 25, 2012 9:12 AM
    Thursday, January 19, 2012 3:27 PM