Is there a way to write a singleton class in c and then transferring it as a resource through NIF to erlang?
Resources are just pointers to memory. These pointers could be the direction of an instance of a class (as much of a singleton as you want it to be), thus sharing it with whoever has a copy of the resource or another resource pointing to the same memory.
Keep in mind the following:
Access to the memory should be synchronized, maybe using mutexes or condition variables.
Resources can be sent across nodes, but they are only relevant in the node that created it. If you try to derefernce a resource in another node, you'll get an error.
If a resource is left without references, it may be GC'd like any other term (you're able to provide a destructor). If a resource goes to another node and back, without saving a reference to the resource, it may have been collected.
Other than that creating the singleton is "as simple" as:
Initialize the memory during NIF module loading, storing it in the module's priv data
Create resources pointing to that memory, use the resources as you want
Access the resource memory through proper synchronization methods
Related
Please note that I am asking about a strictly dart only application this does not concern flutter in any means, dartvm refers to the dart virtual machine.
As far as I understand Dart's idea of reactive state is implemented through streams, the responsibility of handling the lifetime of a stream object is given to the programmer, at runtime one could manipulate the stream as they see fit according to what works for their design by adding to the stream; listening to it or disposing it.
My question is this, Is it necessary that I need to call the dispose() method of a stream before my application quits? If I do, how do I go about accomplishing that? Hooking into the VM state isn't well documented and using ProcessSignal listeners is not portable, If I don't, does the GC handle this case? What's the best practice in this case?
Dart streams do not have a dispose method. Therefore you don't need to call it.
But just to give a little more detail ...
Dart streams are many things. Or rather, streams are pretty simple, they're just a way to provide a connection between code which provides events and code which consumes events. After calling listen, the stream object is no longer part of the communication, events and pushback goes directly between the event source (possibly a StreamController) and the consumer (a StreamSubscription).
Event providers are many things.
Some events are triggered just by code doing things. There is no need to clean up after those, it's just Dart objects like everything else, and they will die with the program, and can be garbage collected earlier if no live code refers to them.
Some events are triggered by I/O operations on the underlying operating system. Those will usually be cleaned up when the program ends, because they are allocated through the Dart runtime system, and it knows how to stop them again.
It's still a good idea to cancel the subscription as soon as you don't need any more events. That way, you won't keep a file open too long and prevent another part of the program from overwriting it.
Some code might allocate other resources, not managed by the runtime, and you should take extra care to say when that resource is no longer needed.
You'll have to figure that out on a case-by-case basis, by reading the documentation of the stream.
For resources allocated through dart:ffi, you can also use NativeFinalizer to register a dispose function for the resource.
Generally, you should always cancel the subscription if you don't need any more events from a stream. That's the one thing you can do. If nothing else, it allows garbage collection to collect things a little earlier.
Is Dart smart enough to automatically dispose variables? for instance in the following code
class Foo {
final streamController = StreamController<int>.broadcast();
final textController = TextEditingController();
}
Must I manually call textController.dispose() and streamController.close()
Dart is a garbage collected language. If an object cannot be accessed by any code any more, if it makes not difference to the program whether it exists or not, the value might eventually be garbage collected. That will necessarily be completely invisible to the program, it's just a memory optimization to not keep things around which makes no difference.
Whether an object is actually unreachable/garbage-collectible depends on whether the program or the run-time system keeps a reachable reference to it, directly or indirectly.
Some objects are kept alive by the run-time system. For example, an open file needs to be remembered so that the system can close it and release the resource when the program ends, whether your code remembers it or not. In general, an allocated system resource should always be assumed to be alive in some way, and you need to dispose/close/cancel it to be sure it's released.
Dart does not try to guess whether one variable of an object is unreachable when the object itself is reachable. In the given example, if a Foo object instance is reachable, then so is the values of its variables. (If there is literally no references to foo.streamController anywhere in the program, including through dynamic invocations, that variable might be optimized away by the compiler, but I wouldn't depend on it).
If there is no reference to a Foo object, then whether the values of the variables are garbage collected depends on whether there are other references to them. I'll assume you're not keeping them around yourself, so the question is whether they are remembered by the run-time system.
I can't speak for TextEditingController. I'm guessing it's a Flutter thing. I do not know whether it contains any system resources.
The stream controller is only kept alive as long as its stream or that stream's listeners.
If there are no current listeners on the controller, and no-one has stored foo.streamController.stream anywhere, there won't be any references to the controller.
Even if there are listeners, StreamSubscriptions, then if those subscriptions are not reachable, then the controller also isnt'.
(The one exception may be while a new event has recently been added to the controller, and a system timer has been set to deliver the event shortly later, but that's only for a very short while).
From the User's Guide:
Sometimes you want to limit the number of times an #Inject-constructed
class is instantiated or a #Provides method is called, but you don’t
need to guarantee that the exact same instance is used during the
lifetime of any particular component or subcomponent.
Why would I use that instead of #Singleton?
Use #Singleton if you rely on singleton behavior and guarantees. Use #Reusable if an object would only be a #Singleton for performance reasons.
#Reusable bindings have much more in common with unscoped bindings than #Singleton bindings: You're telling Dagger that you'd be fine creating a brand-new object, but if there's a convenient object already created then Dagger may use that one. In contrast, #Singleton objects guarantee that you will always receive the same instance, which can be much more expensive to enforce.
In general, Dagger and DI prefer unscoped objects: Creating a new object is a great way to keep state tightly-contained, and allows for objects to be garbage-collected as soon as the dependent object can. Dagger shows some of this preference built-in: In Dagger unscoped objects can be mixed in to any component or module, regardless of whether the component is scope-annotated. This type of unscoped binding is also useful for stateless objects like injectable (mockable) utility classes and implementations of strategy, command, and other polymorphic behavioral design patterns: The objects should be bound globally and injected for testing/overrides, but instances don't keep any state and short-lived or disposable.
However, in Android and other performance- and memory-constrained environments, it goes against performance recommendations to create a lot of temporary objects (as described on android.com but removed since January 2022), because instance creation and garbage collection are both more-expensive processes than on desktop VMs. This leads to the pragmatic solution of marking an object #Singleton, not because it's important to always get the same instance, but just to conserve instances. This works, but is semantically-weak, and also has memory and speed implications: Your short-lived util or strategy pattern object now has to exist as long as your application exists, and must be accessed through double-checked locking, or else you risk violating the "one instance only" #Singleton guarantee that is unnecessary here. This can be a source of increased memory usage and synchronization overhead.
The compromise is in #Reusable bindings, which have instance-conserving properties like #Singleton but are excepted from the scope-matching #Component rule just like unscoped bindings—which gives you more flexibility about where you install them. (See tests.) They have a lifespan only as long as the outermost component that uses them directly, and will opportunistically use an instance from an ancestor to conserve further, but without double-checked locking to save on creation costs. (Consequently, several instances of a #Reusable object may exist simultaneously in your object graph, particularly if they were requested on multiple threads at the same time.) Finally, and most importantly, they're a signal to you and future developers about the way the class is intended to be used.
Though the cost is lower, it's not zero: As Ron Shapiro notes on Medium, "Reusable has many of the same costs as Singleton. It saves synchronization, but it still forces extra classes to be loaded at app startup. The real suggestion here is to never scope unless you’ve profiled and you’ve seen a performance improvement by scoping." You'll have to evaluate the speed and memory effects yourself: #Reusable is another useful tool in the toolbox, but that doesn't mean it's always or obviously a good choice.
In short, #Singleton would work, but #Reusable has some distinct performance advantages if the whole point is performance instead of object lifecycle. Don't forget to measure performance before and after you mark an instance #Reusable, to make sure #Reusable is really a benefit for your use case.
Follow-up question from saiedmomen: "Just to be 100% clear things like okhttpclient, retrofit and gson should be declared #Reusable. right??"
Yes, in general I think it'd be good to declare stateless utilities and libraries as #Reusable. However, if they secretly keep some state—like handling connection limits or batching across all consumers—you might want to make them #Singleton, and if they are used very infrequently from a long-lived component it might still make sense to make them scopeless so they can be garbage-collected. It's really hard to make a general statement here that works for all cases and libraries: You'll have to decide based on library functionality, memory weight, instantiation cost, and expected lifespan of the objects involved.
OkHttpClient in particular does manage its own connection and thread pools per instance, as Wyko points out in the comments, and Albert Vila Calvo likewise notes Retrofit's intended-singleton behavior. That would make those good candidates for #Singleton over #Reusable. Thanks Wyko and Albert!
I have created WCF application which is running on Windows Service. It was installed using Windows Installer. I have followed procedure mentioned in following article for same.
http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic4
Most WCF properties are kept as default for net.tcp protocol, per call instance and so on.
Memory consumption of service keeps on increasing after every call and does not decrease. At the end it throws OutOfMemory consumption.
Application returns very heavy string based data. With memory-profiler I found memory is still allocated to string objects and increases during call.
As per my understanding string is managed objects should release data once out of scope.
Let me know if any other configuration/coding information is needed specifically.
There must be something keeping references to those strings in the code. Can you use your profiler to trace the references that are keeping the string objects alive?
After many unsuccessful attempts to handle LOH (http://msdn.microsoft.com/en-us/magazine/cc534993.aspx) which was very large string in my context, I have created custom class to handle it.
Instead of storing large string in single object am storing it as collection of small strings in custom object. .NET disposed it properly without creating above mentioned problem.
Other possible solution with worked for me is to use file object to store large file and access it as text reader. This works well and keeps footprint of application small. Unfortunately for me it did not work and accessing file location was not allowed for application.
It would be very difficult to answer this question without some code to look at. You can always call GC.Collect(GC.MaxGeneration) to force garbage collection and see if this doesn't reduce your memory consumption. Ideally this would only be temporary code to track down what is going on in the application. If forcing garbage collection does not reduce memory consumption then references to the strings must be being retained, via static member variables or whatever: having no conception of what the code is, any theory would be a shot in the dark
I am using a TWebModule with Apache. If I understand correctly Apache will spawn another instance of my TWebModule object if all previous created objects are busy processing requests. Is this correct?
I have created my own SessionObject and have created a TStringList to store them. The StringList is created in the initialization section at the bottom of my source code file holding the TWebModule object. I am finding initialization can be called multiple times (presumably when Apache has to spawn another process).
Is there a way I could have a global "Sessions" TStringlist to hold all of my session objects? Or is the "Safe", proper method to store session information in a database and retrieve it based on a cookie for each request?
The reason I want this is to cut down on database access and instead hold session information in memory.
Thanks.
As Stijn suggested, using a separate storage to hold the session data really is the best way to go. Even better is to try to write your application so that the web browser contains the state inherently in the design. This will greatly increase the ability to scale your application into the thousands or tens of thousands of concurrent users with much less hardware.
Intraweb is a great option, but suffers from the scale issue in the sense that more concurrent users, even IDLE users, require more hardware to support. It is far better to design from the onset a method of your server running as internally stateless as possible. Of course if you have a fixed number of users and don't expect any growth, then this is less of an issue.
That's odd. If initialization sections get called more than once, it might be because the DLL is loaded in separate process spaces. One option I can think up is to check if the "Sessions" object already exists when you create it on initialization. If the DLL really is loaded in separate processes, this will not help, and then I suggest writing a central Session storage process and use inter-process-communication from within your TWebModule (there are a few methods: messages, named pipes, COM...)
Intraweb in application mode really handles session management and database access very smoothly, and scales well. I've commented on it previously. While this doesn't directly answer the question you asked, when I faced the same issues Intraweb solved them for me.