How do I know which event to listen to?
For example gulp.dest fires the finish event and then somewhat later the end event. Some other streams only fire the finish event. When I have a method that returns a stream (could be a read or write stream) and I execute the method, how can I wait for the returned stream to be finished? When do I have to register for the finish and when for the end event?
The gulp.dest object is a Transform object - it handles reading from the (piped) source and writing to the destination. The 'end' event is emitted by the reader, while the 'finish' event is emitted by the writer.
If you are interested in ensuring the reading completes correctly, use .on('end'). See: https://nodejs.org/api/stream.html#stream_event_end.
Readable streams will emit this once data has been completely consumed by the stream. So there may be cases when it doesn't fire, due to the internal logic of the transformation or to an error condition.
If it is the completion of the writing you are interested in, then use .on('finish') instead. See: https://nodejs.org/api/stream.html#stream_event_finish.
Writable streams will emit this after data has been flushed to the underlying system. So in cases where expected read errors are handled, or where the transformation ends the reading early, this event should still be fired. As I understand it, this won't fire if the writing fails unexpectedly.
Related
I've just worked with Gulp and seeing this:
gulp.src('..')
.pipe(gulp.dest('..'))
.on('end', function() { });
I want to know where the end event is declared and the full list of events like start, end ... ?
Thank you
Gulp's streams are just regular Node.js streams that operate in object mode. The objects emitted in those streams are vinyl file objects.
More specifically gulp's streams are of type stream.Transform meaning they implement both the stream.Readable and stream.Writable interfaces. As such they support all the events supported by those two types:
stream.Readable
'close' event:
Emitted when the stream and any of its underlying resources (a file descriptor, for example) have been closed.
'data' event:
switch the stream into flowing mode. Data will then be passed as soon as it is available.
'end' event:
This event fires when there will be no more data to read.
'error' event:
Emitted if there was an error receiving data.
'readable' event:
When a chunk of data can be read from the stream
stream.Writable
'close' event:
Emitted when the stream and any of its underlying resources (a file descriptor, for example) have been closed.
'drain' event:
If a stream.write(chunk) call returns false, then the 'drain' event will indicate when it is appropriate to begin writing more data to the stream.
'error' event:
Emitted if there was an error when writing or piping data.
'finish' event:
When the stream.end() method has been called, and all data has been flushed to the underlying system
'pipe' event:
emitted whenever the stream.pipe() method is called
'unpipe' event:
emitted whenever the stream.unpipe() method is called
I have a processing loop on the host, where I record an event in a GPU stream. Then another stream waits for that event (waits for event's state "set" or "true"). Will this function (cudaStreamWaitEvent) unset this event (so, switching it to "unset" or "false")? If not, what CUDA function I can use to unset this event?
This sounds very much like an XY question. You might be better off describing at a higher level what it is you are trying to accomplish, or what problem you are facing or think you are facing.
cudaStreamWaitEvent does not "unset" an event.
When the event is encountered in the stream, then cudaStreamWaitEvent will unblock, and any subsequent calls to cudaStreamWaitEvent on the same event will immediately unblock (assuming no cudaEventRecord has again been issued for that event). This behavior is easy to prove with a trivial code sample.
The function that "unsets" a cudaEvent is cudaEventRecord(). Any cudaStreamWaitEvent calls issued after that event gets recorded will wait again, until it is encountered again.
You may want to read the runtime API documentation for cudaEventRecord and cudaStreamWaitEvent. Note the following excerpts:
cudaEventRecord:
If cudaEventRecord() has previously been called on event, then this call will overwrite any existing state in event. Any subsequent calls which examine the status of event will only examine the completion of this most recent call to cudaEventRecord().
cudaStreamWaitEvent:
The stream stream will wait only for the completion of the most recent host call to cudaEventRecord() on event.
Sometimes I'm coding in a wrong way my polymer 1.0 web app and stuff stops to work properly. Like setting data to some custom element and then immediately trying to read some data out of it (that depends on the data just set) (because I don't know better). Sometimes this doesn't work. Most of the time this.async will help me out, but sometimes it will not. However, setTimeout has never ever failed me in these kind of situations. Most of the time calling setTimeout without providing wait time will work just as well.
For a long time I thought that this.async(function(){...}) is the same as setTimeout(function(){...}). Because sometimes code inside this.async will fail to see changes in custom element's data while code inside setTimeout will not.
Are these two methods are implemented in different way?
this.async adds your function to the start of the event queue, while setTimeout adds it to the end. If you use setTimeout other functions may have been executed before your function is called, causing the changes that you can see in your data.
From the documentation of this.async:
If no wait time is specified, runs tasks with microtask timing (after the current method finishes, but before the next event from the event queue is processed)
setTimeout on the other hand will add your function to the end of the queue as is described in the section "Adding Messages" of this article.
Calling setTimeout will add a message to the queue after the time passed as second argument. If there is no other message in the queue, the message is processed right away; however, if there are messages, the setTimeout message will have to wait for other messages to be processed. For that reason the second argument indicates a minimum time and not a guaranteed time
I am reading files from disc that have information I need to display to the user. I set up an event listener that flags when the file is loaded- that's easy. However, that adds a delay before I can display the information, and it appears that doing a simple loop in the main code to wait for the file to be loaded does not work:
while (fileComplete == false);
Essentially that simply freezes the code- the file does not load while that loop functions. I can add a timer that checks every few milliseconds to see if fileComplete == true, but I'm wondering if there is a better way. Ideas?
Flash is by default single-threaded, this means if you're initiating an asynchronous process, you need to release the code flow for Flash engine to actually complete the process. Doing an infinite loop like yours does NOT release the code flow, so you should drop this idea. Instead, you should either blindly wait for Event.COMPLETE event and do the post-load actions in the listener, or you should listen for Event.ENTER_FRAME and check for the flag you're setting in Event.COMPLETE listener. The former approach is cleaner.
Let suppose I create a class, and in this class I declare a method that will run a loop.
My question is what will be behavior of loop, if I dispose the object of class and condition of loop is yet true - will loop execute or terminate.
Usually the object (variable) is managed by a single thread. So you may not be able dispose of easily because the thread is still running in the loop. If you mult-thread and you call in a method that modifies this variable (your object) on the a different thread you may crash your program. If your loop in a UI thread which has a message pump (sta thread) and you call a method directly from another thread then you app will crash as this is not allowed.
All in all what do you want to do ? Mark Byers's condition "The code keeps running" is the most possiable outcome of this I think. But you have a bug either way - don't attempt to drive a car and then just jump out of it without stopping.