If i have two SignalProducers (really they are API service requests so they only send 'next' once), and combine them with combineLatest (as i want to dismiss a loading spinner once both finish), what happens if one of them fails? Or both fail?
Does 'failed' get called (once or twice?) on the combined signal?
If one fails and the other succeeds, will 'next' be called on the combined signal?
Failure of any signal will cause the entire combined signal to error and stop subscription.
If one signal sends its first next and the other signal sends an error as its first value then the next will be lost, combineLatest: is only called once all signals send their first next value.
subscribeError: is only called once. Errors work in a monadic way where they bubble up the chain and stop the whole signal.
If you want to subvert this then you can use the catch:, catchTo:, or retry methods to handle errors.
(Sorry for talking about the Objective-C methods, I don't know the Swift syntax).
Related
I want to know if there is a way to queue up accessibility readouts or element focus events one after another.
If I use either: UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, "My Error Message")
or:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, self.continueButton)
The second call will interrupt the readout that is currently being read.
And obviously, if you use Dispatch with Delay, it's not robust, because different languages have different lengths of content, and also the user has a different readout speed set, which may be set to very slow. So how can I "queue up" multiple focus/read out events and ensure that only one of them gets read out at a time in sequence?
After you post your first announcement you need to wait for UIAccessibilityAnnouncementDidFinishNotification (see more here) before you post the 2nd one.
So build a queue (a set could do it) and whenever UIAccessibilityAnnouncementDidFinishNotification is triggered by the system just pop the first notification in your set (if present) and fire it away.
I'm having a difficult time trying to understand how the control flow in protractor work in relation to how JS event loop works. Here is what I know so far:
Protractor control flow stores commands that return promises in a queue. The first command will be at the front of the queue and the last command will be at the back. No command will be executed until the command in front of it has its promise resolved.
JS event loop stores asynchronous task (callbacks to be specific). Callbacks are not executed until all functions in the stack have completed and the stack is empty. Before running each callback, there is a check on whether the stack is empty or not.
so lets take this code for example. The code is basically clicking a search button and a api request is made. Then after data is returned, it checks whether the field that stores the returned data exists.
elem('#searchButton').click(); //will execute a api call to retrieve data
browser.wait(ExpectedConditions.presenceOf(elem('#resultDataField'),3000));
expect(elem('#resultDataField').isPresent()).toBeTruthy();
So with this code, I'm able to get it to work. But I don't know how it does it. How is the event loop applied in this scenario?
The core of the ControlFlow implementation is in runEventLoop_ (in Selenium's promise.js implementation).
As I understand it, the ControlFlow registers a call to runEventLoop_ with the JS event loop (e.g., with a 0-second timeout or somesuch). The call to runEventLoop_ can be thought of as a single iteration of a normal event loop. It registers code to actually run a scheduled task (i.e., actually do the work you queued up during your it). Once that task completes or fails (e.g., by hooking its async promise callbacks) the next iteration of runEventLoop_ is scheduled (see the calls to scheduleEventLoop in runEventLoop_).
There is some complexity when a callback ends up registering new promises (those need to be "inserted" before the old next event, this is accomplished by creating a "nested" control flow. Mostly you should never have to know this.)
I am reading libpq reference. It has both of sync and async methods. Bu I discovered something strange.
When I see PQsendQuery function, it seems to send a query and return immediately. And I expected a callback function to get notified, but there was no such thing and the manual says to poll for data availability.
I don't understand why async method is written in polling way. Anyway, as libp is the official client implementation, I believe there should be a good reason for this design. What is that? Or am I missing correct callback stuffs mentioned somewhere else?
In the execution model of a mono-threaded program, the execution flow can't be interrupted by data coming back from an asynchronous query, or more generally a network socket. Only signals (SIGTERM and friends) may interrupt the flow, but signals can't be hooked to data coming in.
That's why having a callback to get notified of incoming data is not possible. The piece of code in libpq that would be necessary to emit the callback would never run if your code doesn't call it. And if you have to call it, that defeats the whole point of a callback.
There are libraries like Qt that provide callbacks, but they're architectured from the ground up with a main loop that acts as an event processor. The user code is organized in callbacks and event-based processing of incoming data is possible. But in this case the library takes ownership of the execution flow, meaning its mainloop polls the data sources. That just shifts the responsibility to another piece of code outside of libpq.
This page is describing how I can get be notified for async result fetch.
http://www.postgresql.org/docs/9.3/static/libpq-events.html#LIBPQ-EVENTS-PROC
PGEVT_RESULTCREATE
The result creation event is fired in response to any query execution
function that generates a result, including PQgetResult. This event
will only be fired after the result has been created successfully.
typedef struct {
PGconn *conn;
PGresult *result; } PGEventResultCreate; When a PGEVT_RESULTCREATE event is received, the evtInfo pointer should be cast to a
PGEventResultCreate *. The conn is the connection used to generate the
result. This is the ideal place to initialize any instanceData that
needs to be associated with the result. If the event procedure fails,
the result will be cleared and the failure will be propagated. The
event procedure must not try to PQclear the result object for itself.
When returning a failure code, all cleanup must be performed as no
PGEVT_RESULTDESTROY event will be sent.
Is there any way to monitor all signals emitted from a widget with GTK3? I know that the event signal is emitted before an event, but I'm not sure of the distinction between "event" and "signal" in GTK terminology - as this does not seem to capture all signals.
I know GDK has a function gdk_set_show_events but this mostly shows events which are sent to the window from the operating system. Is there a GTK3 equivalent?
There is not built in function AFAIK, but I'm sure you can hack something together yourself:
Use g_signal_lookup to get all signal ids for a gtype. Then use g_signal_add_emission_hook on each signal of your instance to register a hook to be called whenever that particular signal is emitted. Inside the hook function, you're provided with the signal id via *ihint, from which g_signal_query should provide you with all the information you need to print debug messages. (I didn't test it, but it should work)
Note that this will unfortunately not work for signals defined with G_SIGNAL_NO_HOOKS.
Use g_signal_lookup to get all signal ids
It's a little more complicated than described. In order to use g_signal_lookup, you first need a signal-name. If you want to monitor every signal independent of the object-type, you first need to list all signals of the specific instance-type. This can be arranged by g_signal_list_ids for exactly one single GType. To get really ALL signals emitted on the instance, you need to iterate over all parent-types of this instance. You can do this by using g_type_parent.
I have build some utility-functions by myself, that provide this functionality for the same debugging purpose the question was intended. You can connect an Emission-Hook for all signals of a GObject-instance with gemu_glib_util_connect_to_all_signals or connect an emission-Hook to a GtkWidget-instance and all its children with gemu_gtk_util_signal_connect_to_widget_children.
In my last question, OpenCl cleanup causes segfault. , somebody hinted that missing event handling, i.e. not waiting for code to finish, could cause the seg faults. Since then I looked again into the tutorials I used, but they don't pay attention to events (Matrix Multiplication 1 (OpenCL) and NVIDIA_OpenCL_GettingStartedLinux.pdf) or talk about it in detail and (for me) understandable.
Do you know a tutorial on where and how to wait in OpenCL?
Merci!
I don't have a tutorial on events in OpenCL, and I'm by no means an expert, but since no one else is responding...
As a rule of thumb, you'll need to wait for any function named clEnqueue*. Those functions return immediately before the job is done. The easiest way to make sure your queue is finished is to call clFinish(). It won't return until the entire queue has completed.
If you want to get a little fancier, most of the clEnqueue* functions have an optional cl_event parameter that you can pass in. You can check on a particular event with clGetEventInfo(), and you can wait for a particular set of events to finish with clWaitForEvents().