I have a bunch of functions in an array allFunctions. I want them to be executed one after the other with delay between them. The closest I can think of is:
result = Q();
allFunctions.forEach(function(fn) {
result = result.then(fn).delay(1000);
})
Is this possible to do with the Q.all syntax?
Thank you in advance :)
Not in a meaningful way, a promise is an already started operation and Q.all waits for all actions to finish together.
What you currently have is the common way to do this, and it's very similar to the synchronous version (a for loop with sleep).
You can shorten it a bit with Array.prototype.reduce though:
var result = allFunctions.reduce(function(prev,fn){
return prev.then(fn).delay(1000);
},Q());
You can nest between your functions a Q().delay( 1000 )
This means that you would have to map your function array to:
function delay(){ return Q.delay(1000); }
var functions = [ f1, delay, f2, delay, f3 ];
Q.all will not run your functions sequentially, what you are doing with prev.then is an interesting hack, but you can also run it the way Q suggests it (more info here https://github.com/kriskowal/q#sequences):
var results = functions.reduce(Q.when, Q(initialVal));
Having the delays intercallated in your function array will also provide more control over the delays (if you eventually want different time delays)
Related
I'm having trouble understanding the point of a blocking Observable, specifically blockingForEach()
What is the point in applying a function to an Observable that we will never see?? Below, I'm attempting to have my console output in the following order
this is the integer multiplied by two:2
this is the integer multiplied by two:4
this is the integer multiplied by two:6
Statement comes after multiplication
My current method prints the statement before the multiplication
fun rxTest(){
val observer1 = Observable.just(1,2,3).observeOn(AndroidSchedulers.mainThread())
val observer2 = observer1.map { response -> response * 2 }
observer2
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(AndroidSchedulers.mainThread())
.subscribe{ it -> System.out.println("this is the integer multiplie by two:" + it) }
System.out.println("Statement comes after multiplication ")
}
Now I have my changed my method to include blockingForEach()
fun rxTest(){
val observer1 = Observable.just(1,2,3).observeOn(AndroidSchedulers.mainThread())
val observer2 = observer1.map { response -> response * 2 }
observer2
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(AndroidSchedulers.mainThread())
.blockingForEach { it -> System.out.println("this is the integer multiplie by two:" + it) }
System.out.println("Statement comes after multiplication ")
}
1.)What happens to the transformed observables once no longer blocking? Wasnt that just unnecessary work since we never see those Observables??
2.)Why is my System.out("Statement...) appear before my observables when I'm subscribing?? Its like observable2 skips its blocking method, makes the System.out call and then resumes its subscription
It's not clear what you mean by your statement that you will "never see" values emitted by an observer chain. Each value that is emitted in the observer chain is seen by observers downstream from the point where they are emitted. At the point where you subscribe to the observer chain is the usual place where you perform a side effect, such as printing a value or storing it into a variable. Thus, the values are always seen.
In your examples, you are getting confused by how the schedulers work. When you use the observeOn() or subscribeOn() operators, you are telling the observer chain to emit values after the value is move on to a different thread. When you move data between threads, the destination thread has to be able to process the data. If your main code is running on the same thread, you can lock yourself out or you will re-order operations.
Normally, the use of blocking operations is strongly discouraged. Blocking operations can often be used when testing, because you have full control of the consequences. There are a couple of other situations where blocking may make sense. An example would be an application that requires access to a database or other resource; the application has no purpose without that resource, so it blocks until it becomes available or a timeout occurs, kicking it out.
Second attempt here, I just wanted to know if this is considered a recursive function.
The purpose of the function is to take a string and
if the the first element is equal to the last element
then append the last element to a list and return nothing,
else call istelf and pass the same string from index [1]
finally append the first element to the list
I know that error checking needs to be done on the if statement. However I am only doing this to try and get my head around recursion...Struggling to be honest.
Also I would never write a program like this if it where anything but trivial I just wanted to check if my understanding is correct so far.
def parse(theList):
theList.reverse()
parsedString = ''.join(theList)
return parsedString
def recursiveMessage(theString):
lastElement = theString[len(theString) - 1]
if theString[0] == lastElement:
buildString.append(theString[0])
return None
else:
recursiveMessage(theString[1::])
buildString.append(theString[0])
toPrint = "Hello Everyone!"
buildString = []
recursiveMessage(toPrint)
print(parse(buildString))
Thanks again.
Is this recursive?
If at any point in a function's execution it calls itself, then it is consider recursive. This happens in your example, so recursiveMessage is indeed recursive.
so which is quicker recursion or iteration?
Recursion is usually much slower and consumes more space due to a new stack frame having to be created on the call stack each recursive call. If you know your recursive function will need to be run many times, iteration is the best route.
As an interesting side note, many compilers actually optimize a recursive function by rolling it out into a loop anyways.
IF I have an array, names = ['Jon', 'Stewart', 'Oliver'], I want to get all 3-tuples and 2-tuples:
Jon, Stewart, Oliver
Jon, Stewart
Stewart, Oliver
Oliver, Jon
What algorithm can I use for this? The array can also be VERY large (200+ items), so whatever code I use should be asynchronous in nature.
I think you might be confusing "asynchronous" here. The process of creating the tuples will always block. So possibly what you'll want to do is create an algorithm that only generates a tuple when it's required, based on some parameters, then cache it for later.
Since you've tagged this as node.js I'm going to assume that's the programming language of interest. Based on that assumption, and the assumption that you actually don't want this to be blocking, your best bet is to spawn multiple processes and pipe out the process creating these tuples. Here's a very rough example script (emphasis on rough):
var cluster = require('cluster');
var names = ['Jon', 'Stewart', 'Oliver'];
if (cluster.isWorker) {
var count = +process.env.tupple_count;
var tuples = [];
// Process tuple here, then return it.
process.send(JSON.stringify(tuples));
return;
}
cluster.fork({ tupple_count: 2 }).on('message', function(msg) {
// Receive tuple here:
var tuple = JSON.parse(msg);
console.log(tuple);
});
// Go about my life.
Then you could write a general algorithm to return these. Here's a good link on how to do this: Algorithm to return all combinations of k elements from n
I am just starting to learn the ins-and-outs of multithread programming and have a few basic questions that, once answered, should keep me occupied for quite sometime. I understand that multithreading loses its effectiveness once you have created more threads than there are cores (due to context switching and cache flushing). With that understood, I can think of two ways to employ multithreading of a recursive function...but am not quite sure what is the common way to approach the problem. One seems much more complicated, perhaps with a higher payoff...but thats what I hope you will be able to tell me.
Below is pseudo-code for two different methods of multithreading a recursive function. I have used the terminology of merge sort for simplicity, but it's not that important. It is easy to see how to generalize the methods to other problems. Also, I will personally be employing these methods using the pthreads library in C, so the thread syntax mildly reflects this.
Method 1:
main ()
{
A = array of length N
NUM_CORES = get number of functional cores
chunk[NUM_CORES] = array of indices partitioning A into (N / NUM_CORES) sized chunks
thread_id[NUM_CORES] = array of thread id’s
thread[NUM_CORES] = array of thread type
//start NUM_CORES threads on working on each chunk of A
for i = 0 to (NUM_CORES - 1) {
thread_id[i] = thread_start(thread[i], MergeSort, chunk[i])
}
//wait for all threads to finish
//Merge chunks appropriately
exit
}
MergeSort ( chunk )
{
MergeSort ( lowerSubChunk )
MergeSort ( higherSubChunk )
Merge(lowerSubChunk, higherSubChunk)
}
//Merge(,) not shown
Method 2:
main ()
{
A = array of length N
NUM_CORES = get number of functional cores
chunk = indices 0 and N
thread_id[NUM_CORES] = array of thread id’s
thread[NUM_CORES] = array of thread type
//lock variable aka mutex
THREADS_IN_USE = 1
MergeSort( chunk )
exit
}
MergeSort ( chunk )
{
lock THREADS_IN_USE
if ( THREADS_IN_USE < NUM_CORES ) {
FREE_CORE = find index of unused core
thread_id[FREE_CORE] = thread_start(thread[FREE_CORE], MergeSort, lowerSubChunk)
THREADS_IN_USE++
unlock THREADS_IN_USE
MergeSort( higherSubChunk )
//wait for thread_id[FREE_CORE] and current thread to finish
lock THREADS_IN_USE
THREADS_IN_USE--
unlock THREADS_IN_USE
Merge(lowerSubChunk, higherSubChunk)
}
else {
unlock THREADS_IN_USE
MergeSort( lowerSubChunk )
MergeSort( higherSubChunk )
Merge(lowerSubChunk, higherSubChunk)
}
}
//Merge(,) not shown
Visually, one can think of the differences between these two methods as follows:
Method 1: creates NUM_CORES separate recursion trees, each one having a single core traversing it.
Method 2: creates a single recursion tree but has all cores traversing it. In particular, whenever there is a free core, it is set to work on the "left child subtree" of the first node where MergeSort is called after the core is freed.
The problem with Method 1 is that if it is the case that the running time of the recursive function varies with the distribution of values within each initial subchunk (i.e. the chunk[i]), one thread could finish much faster leaving a core sitting idle while the others finish. With Merge Sort this is not likely to be the case since the work of MergeSort happens in Merge whose runtime isn't affected much by the distribution of values in the (sorted) subchunks. However, with a more involved recursive function, the running time on one subchunk could be much longer!
With Method 2 it is possible to have the same problem. Again, with merge sort its not clear since the running time for each subchunk is likely to be similar, but the line //wait for thread_id[FREE_CORE] and current thread to finish would also require one core to wait for the other. However, with Method 2, all calls to Merge run ASAP as opposed to Method 1 where one must wait for NUM_CORES calls to MergeSort to finish and then do NUM_CORES - 1 merges afterward (although you can multithread this as well...to an extent)
(though the syntax might not be completely correct)
Are both of these methods used in practice? Are there situations where one is more beneficial over the other? Is this the correct way to implement Method 2? (in this case, THREADS_IN_USE is a semaphore?)
Thanks so much for your help!
as I use Node.js for not too long time yet, I've ran into a following problem. I understand that using callback-driven paradigma we need to convert loops we used in synchronous code into recursion. My problem is I cannot understand how deep node can go with recursion, results with different tests are inconsistent. For example, I tried code I've found on Web:
var depth = 0;
(function recurseBaby() {
// log at every 500 calls
(++depth % 500) || console.log(depth);
// bail out ~100K depth in case you're special and don't error out
if (depth > 100000) return;
recurseBaby();
})();
It gives me node exception (max recursion depth) after 18500 recursions.
So I tried to add some functionality, like working with queue:
var depth = 0,
Memcached = require('memcached'),
memcacheq = new Memcached('127.0.0.1:22201');
(function recurseBaby() {
// log at every 500 calls
(++depth % 500) || console.log(depth);
// bail out ~10M depth in case you're special and don't error out
if (depth > 10000000) return;
memcacheq.set('test_queue', 'recurs' + depth, 0, function (error, response) {
return recurseBaby();
});
})();
It didn't finish yet, but works so far for more than 4 million recursions (and queue is actually getting filled). So I would like to clarify, how recursion depth limit works in node. My guess would be that if I do something in that recursively called function, node has more time to free call stack, but I may be terribly wrong. Any clarifications from more experienced node users are welcome.
There is no recursion in your second example at all.
In the first example you clearly have a recursive call.
In the second example a call is made to memcacheq.set which returns immediately, and then your function returns. It will have made a node somewhere of the function to call when the triggered event happens at some later time.
--- No recursive call has been made ---
At some point in time later the memcache function will finish and queue an event to the event queue to trigger your callback.
But note that this is done from an event in the event queue, NOT by a direct recursive call from your function which has probably long since returned.