My app fires off a thread specifically for checking the status of a process. It fires every 5-10 seconds:
if(!monitorTask){
MYLog(100,#"Monitor task is dead");
return;
}
dispatch_async(monitorTask,^{ // fuckup here
MYLog(150,#"...Checking iTunes");
However it also seems to hang there every so often:
Any clues how to fix/catch this? The app is beachballing but "running" in Xcode just fine - stuck on this instruction:
Are you sure that monitorTask is of type dispatch_queue_t? See these Apple guides for an example of how to create a serial queue
Though I see in your comment that you are creating the queue correctly.
It is also possible that the queue may be deallocated before you can dispatch to it. You may need to perform some memory management on your queue to ensure that it isn't deallocated before you dispatch.
Lastly it is important to note that serial queues are by-and-large used to protect shared resources. If you are just trying to perform a periodic check on a resource (a task that would never write, and only read), then you are going to be better off using a concurrent queue (you should probably just use one of the 4 given global queues,
Or because you are seemingly perpetually checking throughout the lifetime of the application, you could even look into using a Dispatch Source, more specifically a Timer Dispatch Source
I think this may be an Xcode debugger problem, because I cannot replicate it while running the app outside of Xcode :-/
Related
I'm using node-cache to cache data from a CLI application that observes changes in files and caches them to avoid new data processing.
the problem is that I noticed that this cache is destroyed on each command, since each time the tool is called in the terminal a new instance is generated and the old one is destroyed. probably, the data is also destroyed.
I need to keep, for a specific TTL, two things in cache/memory, even if the process ends:
the processed data
the specific instance of fs.watcher, watching and executing caching operations
the question is: how do i do it? I've been searching for days on the internet and trying alternatives and I can't find a solution.
I need to keep ... things in cache/memory, even if the process ends
That's, pretty much by definition, not possible. When a process terminates, all its resources are freed up for use by something else (barring a memory-leak bug in the OS itself).
It sounds like you need to refactor your app into a service that can run in the background and separate front-end that can communicate with it.
I have a question, Node.js uses libuv inside of u core, to manage its event loop and by default works whit 4 threads and process queue whit limit of 1024 process.
Process queue limit
Threads by default
So, because most programmers say it's single thread?
By default, node.js only uses ONE thread to run your Javascript. Thus your Javascript runs as single threaded. No two pieces of your Javascript are ever running at the same time. This is a critical design element in Javascript and is why it does not generally have concurrency problems with access to shared variables.
The event driven system works by doing this:
Fetch event from event queue.
Run the Javascript callback associated with the event.
Run that Javascript until it returns control back to the system.
Fetch the next event from the event queue and go back to step 2.
If no event in the event queue, go to sleep until an event is added to the queue, then go to step 1.
In this way, you can see that a given piece of Javascript runs until it returns control back to the system and then, and only then, can another piece of Javascript run. That's where the notion of "single threaded" comes from. One piece of Javascript running at a time. It vastly simplifies concurrency issues and, when combined with the non-blocking I/O model, it makes a very efficient system, even when lots of operations are "in flight" (though only one is actually running at a time).
Yes, node.js has some threads inside of libuv that are used for things like implementing file system access. But those are only for native code inside the library and do NOT make your Javascript multi-threaded in any way.
Now, recent versions of node.js do have Worker Threads which allow you to actually run multiple threads of Javascript, but each thread is a very separate environment and you must communicate with other threads via messages without the direct sharing of variables. This is relatively new to nodejs version 10.5 (though it's similar in concept to WebWorkers in the browser. These Worker Threads are not used at all unless you specifically engage them with custom programming designed to take advantage of them and live within their specific rules of operation.
A customer wants to flush the queue in one go. However, neither of the batch options seems to be available in Java, so they insist on deleting the queue altogether.
The question is, how do I detect that a queue is no longer there? Is there some kind of a hook? Because my listener will simply be silent and do nothing.
(The queue is created when the worker role starts if it doesn't exist yet, so generally restarting the queue would work. The only problem is, there are many instances so it's a bit problematic to restart it.)
NamespaceManager.QueueExists should get the job done for you.
I have a site which sometimes takes particularly long to process a request (and that's not a defect). 99% of the time it's pretty quick because it almost doesn't do any processing.
I want to show a message that says "Loading" when the site takes long to process the request. My site uses mod_wsgi and Apache. The way I see it, I would respond saying 'Loading' before completing the processing and do one of two things right before:
-spawn a (daemon) thread to take care of the processing.
-communicate through socket with other process and tell it to take care of the processing (most likely send request to http://localhost:8080/do_processing).
What are the pros and cons of one approach vs the other?
Using a separate process is better. It does not have to be hard at all as suggested in another answer as you can use an existing system for doing exactly that such as Celery (http://celeryproject.org/). Relying on in process threads is not necessarily a good idea unless you are going to implement an internal job queueing system of your own to prevent blowing out of number of threads. Also, in a multiprocess server configuration you cant be guaranteed a request comes back to the same process and so not easy to get status of a running operation. Finally, the web server processes could get killed off and thus your background task could also be killed before it finishes. You would need to have a mechanism for holding state which can survive such an event if that was important. Far easier to use something like Celery.
The process route requires quite a bit of a system processing. Creation of a separate process is relatively expensive and slow. However if your process crashes it doesn't affect your main governing process (you will receive the exit status code and will have an opportunity to respawn a new working process). You will also need some sort of InterProcessCommunication layer (can be a socket, pipe, shared memory, etc...) which is adds to complexity if your project.
Threads are lightweight and cheap. All you need to do is to manage concurrent access to shared resources. So it really depends on the task you have in mind. Threads probably will be more likely the appropriate way to implement your task.
I want to make a windows service that monitors another windows service, and make sure that it is working.
sometimes the Win Service that I want to watch stay in the memory (appear in task manager, so it is considered a running service, but the fact is that it is doing nothing, it is dead, its timer is not firing for one reason, which is not the subject for this question).
what I need is to make a watch dog Win Service that somehow reads a value in the memory that the other watched service is periodically writing.
I thought about using Named Pipes but I don't want to add communication issues to my services, I want to know if there is a way to create such a shared memory between 2 applications (possibly using a named system wide Mutex?)
Since you have to deal with detecting a zombie service I don't think using a kernel object like a mutex will help, you need to detect activity. A semaphore isn't a good fit either.
My personal preference would be a named pipe sending small heartbeat messages (since that could be detected across a network as well), but if you want to avoid the complexity of pipe comms - which I guess is understandable - then you could update a DWORD in a predetermined registry key. If both services run under LocalSystem you could write a key/value into HKEY_LOCAL_MACHINE. Run a pump-up timer and watch for changes to the key every so often (watch out for counter wrap-around). You won't have a normal window/message pump so SetTimer is off-limits, but you can still use timeSetEvent or waitable timers.
HKLM won't be available if one of the services runs under a non-admin account, but that's a pretty rare situation for services. Of course all this assumes you have access to the code of both services. Watching a third-party service would severely limit your options.