Hi Uze, As the framework is single-threaded by design, many internal modules operate on global structures. So, the global CborEncoder objects used in oc_rep aren’t an exception, and are in fact an efficiency that takes advantage of the single-threaded design. Consequently, just modifying oc_rep to allocate them dynamically wouldn’t make the APIs thread-safe.
However, (equivalent) thread-safe APIs (with the same signature) can be implemented (wherever they’re necessary) in a thin upper layer, as an accessory, to be used by multi-threaded applications that don’t want to bother with locking themselves. I imagine this’ll be particularly useful in clients and to a limited extent in servers. I am experimenting with such a scheme and should post it once its done. Thanks, -Kishen. - Kishen Maloor Intel Open Source Technology Center From: <iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org>> on behalf of "최우제 (Uze Choi)" <uzc...@samsung.com<mailto:uzc...@samsung.com>> Date: Monday, April 2, 2018 at 1:58 AM To: "iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>" <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: [dev] API proposal for better userability in IoTivity Lite. Hi Kishen, Let me propose new APIs to satisfy followings. Two requirements : Multi Thread Application Code requirement : Easy-to use with consistent API signature Problem : Singleton CborEncoder Root object prevent creating payload in multithread race condition. - Get Response, Notify in Server side and Client side cannot be handled from different thread. It could be done by synchronization handling from App side but not easy to use. How to…. Server Side AS-IS oc_rep_start_root_object(); oc_process_baseline_interface(request->resource); oc_rep_set_boolean(root, state, state); oc_rep_end_root_object(); oc_send_response(request, OC_STATUS_OK); Server Side TO-BE CborEncoder new_rep = oc_rep_create_root_object(); // New Additional : make opaque type for CborEncoder to hide it oc_process_baseline_interface(new_rep, request->resource); // New Additional (with parameter adding) oc_rep_set_boolean(new_rep, state, state); oc_rep_end_root_object(new_rep); // we can remove this call with tinycbor update. oc_send_response(request, new_rep, OC_STATUS_OK); // New Additional (with parameter adding), refer new_rep with g_encoder. Client Side AS-IS oc_init_post(a_light, light_server, NULL, &post2_light, LOW_QOS, NULL) oc_rep_start_root_object(); oc_rep_set_boolean(root, state, state); oc_rep_end_root_object(); oc_do_post(); Client Side TO-BE // oc_init_post(a_light, light_server, NULL, &post2_light, LOW_QOS, NULL) <-- This can be skipped because params are set in new oc_do_post. CborEncoder new_rep = oc_rep_create_root_object(); oc_rep_set_boolean(new_rep, state, state); oc_rep_end_root_object(new_rep); // we can remove this call with tinycbor update. oc_do_post(a_light, light_server, NULL, new_rep, &post2_light, LOW_QOS, NULL); // New Additional (with parameter adding), refer new_rep with g_encoder, This will make API consistent with oc_do_get(……) --- Sumary New API List. --- CborEncoder_opaque oc_rep_create_root_object() oc_process_baseline_interface(new_rep, request->resource) // adding param oc_send_response(request, new_rep, OC_STATUS_OK); // adding param oc_do_post(…..) // adding param
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
