Some questions about source handling
Hi all, Questions: 1. How does a source's event handler accesses data returned by kevent? Data returned by kevent will finally be recorded is ds_data field in _dispatch_source_latch_and_call. The event handler will be called with ds_handler_ctxt, which shoule be do_ctxt. "do_ctxt" can be set by function dispatch_set_context. The problem is: - If a handler need to access ds_data, we have to set a proper do_ctxt (e.g. a do_ctxt of source). That's not convenient. - "ds_data" is a member of dispatch_source_t, and dispatch_source_t is an opaque struct to client code. 2. We have custom source of type DISPATCH_SOURCE_TYPE_DATA_ADD and DISPATCH_SOURCE_TYPE_DATA_OR, and can use dispatch_source_merge_data to fire custom sources. Why we don't have an 'is_level' source? An "is_level" source may not make much sense, but can be attached with cancel handler, this may be useful in some cases. -- Regards, - cee1
On Sep 8, 2010, at 8:42 PM, cee1 wrote:
Questions: 1. How does a source's event handler accesses data returned by kevent?
Data returned by kevent will finally be recorded is ds_data field in _dispatch_source_latch_and_call. The event handler will be called with ds_handler_ctxt, which shoule be do_ctxt. "do_ctxt" can be set by function dispatch_set_context. The problem is: If a handler need to access ds_data, we have to set a proper do_ctxt (e.g. a do_ctxt of source). That's not convenient. It is only inconvenient if you're in the prototyping stage of a project. By the time a project matures, there will surely be a data structure that tracks a connection, and as a part of that connection, a pointer back to the dispatch_source_t. For example:
struct my_connection_s { ... dispatch_source_t source; ... }; ... void my_connection_handler(void *ctxt) { struct my_connection_s *mc = ctxt; printf("new data: %lu\n", dispatch_source_get_data(mc->source)); } ... struct my_connection_s *mc = my_connection_create(); mc->source = dispatch_source_create(...); dispatch_set_context(mc->source, mc); dispatch_source_set_event_handler_f(mc->source, my_connection_handler); dispatch_resume(mc->source); ...
"ds_data" is a member of dispatch_source_t, and dispatch_source_t is an opaque struct to client code. See the example above where dispatch_source_get_data() is used.
2. We have custom source of type DISPATCH_SOURCE_TYPE_DATA_ADD and DISPATCH_SOURCE_TYPE_DATA_OR, and can use dispatch_source_merge_data to fire custom sources. Why we don't have an 'is_level' source?
An "is_level" source may not make much sense, but can be attached with cancel handler, this may be useful in some cases.
If you can think of a practical use for that, then let us know. davez
2010/9/12 Dave Zarzycki <zarzycki@apple.com>
On Sep 8, 2010, at 8:42 PM, cee1 wrote:
2. We have custom source of type DISPATCH_SOURCE_TYPE_DATA_ADD and DISPATCH_SOURCE_TYPE_DATA_OR, and can use dispatch_source_merge_data to fire custom sources. Why we don't have an 'is_level' source?
An "is_level" source may not make much sense, but can be attached with cancel handler, this may be useful in some cases.
If you can think of a practical use for that, then let us know.
I find a case, it's about adding T9 physical keyboard support on Android. We found some input methods already support T9 virtual keyboard but not physical one. So we handle onKeyDown event, translating a physical key press to a touch event on the virtual keyboard, e.g: key '2' -> touchEvent (10, 20) -- (10, 20) is (x,y) in screen coordinates.
Unfortunately synthesizing and sending a touch event will spend some time, causing android prompts not responsible of this program. So synthesizing and sending a touch event should be delayed to another thread. This time, 'is_level' custom source will be useful: ds = dispatch_source_create(DISPATCH_SOURCE_TYPE_DATA_LEVEL, ...); dispatch_source_set_event_handler_f(ds, synthesize_and_send_touch_event); onKeyDown() { dispatch_source_merge_data(ds, KEY_2); } -- Regards, - cee1
On Dec 10, 2010, at 12:46 AM, fykcee1@gmail.com wrote:
2010/9/12 Dave Zarzycki <zarzycki@apple.com> On Sep 8, 2010, at 8:42 PM, cee1 wrote:
2. We have custom source of type DISPATCH_SOURCE_TYPE_DATA_ADD and DISPATCH_SOURCE_TYPE_DATA_OR, and can use dispatch_source_merge_data to fire custom sources. Why we don't have an 'is_level' source?
An "is_level" source may not make much sense, but can be attached with cancel handler, this may be useful in some cases.
If you can think of a practical use for that, then let us know.
I find a case, it's about adding T9 physical keyboard support on Android. We found some input methods already support T9 virtual keyboard but not physical one. So we handle onKeyDown event, translating a physical key press to a touch event on the virtual keyboard, e.g: key '2' -> touchEvent (10, 20) -- (10, 20) is (x,y) in screen coordinates.
Unfortunately synthesizing and sending a touch event will spend some time, causing android prompts not responsible of this program. So synthesizing and sending a touch event should be delayed to another thread. This time, 'is_level' custom source will be useful:
ds = dispatch_source_create(DISPATCH_SOURCE_TYPE_DATA_LEVEL, ...); dispatch_source_set_event_handler_f(ds, synthesize_and_send_touch_event);
onKeyDown() { dispatch_source_merge_data(ds, KEY_2); }
You would not want to implement a stream of keyboard events with an "is level" dispatch source. This is because users expect that keyboard events are not lossy, and a dispatch "is level" source would only tell your code what the last key press was, not the list of key presses that haven't been handled yet. A dispatch queue would be appropriate in this scenario. davez
2010/12/11 Dave Zarzycki <zarzycki@apple.com>
You would not want to implement a stream of keyboard events with an "is level" dispatch source. This is because users expect that keyboard events are not lossy, and a dispatch "is level" source would only tell your code what the last key press was, not the list of key presses that haven't been handled yet. A dispatch queue would be appropriate in this scenario.
Yeah, you are right, I didn't consider it thoroughly, sorry. But I still think we need such custom sources: in some cases like fire multi-times and will only process the last value (like threading.Event<http://www.python.org/doc//current/library/threading.html#threading.Event>API in python). -- Regards, - cee1
participants (3)
-
cee1
-
Dave Zarzycki
-
fykcee1＠gmail.com