Re: [E-devel] [Patch][ecore_con] Refactoring curl port
Hi, Congratulations on EFL1.1 release!!! Now, Can it be added to svn?? :) 2011/11/15 Carsten Haitzler ras...@rasterman.com: On Mon, 14 Nov 2011 18:47:08 +0900 Bluezery ohpo...@gmail.com said: considering the amount of refactoring.. this will have to wait until after 1.1. we are in feature freeze. that means no refactoring. no new features. just bug fixes. Oh, I see. That's better. :) On Mon, Nov 14, 2011 at 6:10 PM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 10:08:09 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Mon, Nov 14, 2011 at 9:57 AM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 09:48:07 +0100 Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. I know nothing about the curl stuff or I would have already reviewed it. My vote is also for Cedric. Due to my limited amount of time and my uncertainty about the idler issue. I would prefer that we wait just one week, let 1.1 go and then put your patch in. Yes, I assumed that had already been decided on. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- BRs, Kim. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On Mon, 5 Dec 2011 14:27:00 +0900 Bluezery ohpo...@gmail.com wrote: Hi, Congratulations on EFL1.1 release!!! Now, Can it be added to svn?? :) 2011/11/15 Carsten Haitzler ras...@rasterman.com: On Mon, 14 Nov 2011 18:47:08 +0900 Bluezery ohpo...@gmail.com said: considering the amount of refactoring.. this will have to wait until after 1.1. we are in feature freeze. that means no refactoring. no new features. just bug fixes. Oh, I see. That's better. :) On Mon, Nov 14, 2011 at 6:10 PM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 10:08:09 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Mon, Nov 14, 2011 at 9:57 AM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 09:48:07 +0100 Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. I know nothing about the curl stuff or I would have already reviewed it. My vote is also for Cedric. Due to my limited amount of time and my uncertainty about the idler issue. I would prefer that we wait just one week, let 1.1 go and then put your patch in. Yes, I assumed that had already been decided on. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com your patch no longer applies. resend one that does and I will review it. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On Mon, 5 Dec 2011 00:32:00 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: your patch no longer applies. resend one that does and I will review it. i actually was fixing it up... though i got called off to do other things today. back to it now. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On Fri, 11 Nov 2011 19:12:09 +0900 Bluezery ohpo...@gmail.com said: in svn! thanks! i fixed up the conflict with current svn too. I have done two more things. Please check attached patch. I have tested using elm_map. I works well. 1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead. 2) I removed complete idler and use ecore_event_add() directly. However, ecore_main_fd_handler_del() sometimes give warnnings because file descriptors cannot be controlled by ecore_con and only curl controls those internally. I think it can be ignored On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/11/2011 09:41 AM, Bluezery wrote: It's my mistake. fixed patch is attached again. I have removed active flag also. I use eina_list_data_find() instead. Also, there is used a lot of idlers. I think all idlers can be removed now, as we only do one multi perform on each fd handler ready. The reason the idlers were added, was that we did multi_perform in loop for 0.1s (or something like that) which clogged the system. Cedric was the one adding the idlers, Cedric??? S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On Mon, 14 Nov 2011 09:48:07 +0100 Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. I know nothing about the curl stuff or I would have already reviewed it. My vote is also for Cedric. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On Mon, Nov 14, 2011 at 9:57 AM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 09:48:07 +0100 Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. I know nothing about the curl stuff or I would have already reviewed it. My vote is also for Cedric. Due to my limited amount of time and my uncertainty about the idler issue. I would prefer that we wait just one week, let 1.1 go and then put your patch in. -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
Oh, I see. That's better. :) On Mon, Nov 14, 2011 at 6:10 PM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 10:08:09 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Mon, Nov 14, 2011 at 9:57 AM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 09:48:07 +0100 Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. I know nothing about the curl stuff or I would have already reviewed it. My vote is also for Cedric. Due to my limited amount of time and my uncertainty about the idler issue. I would prefer that we wait just one week, let 1.1 go and then put your patch in. Yes, I assumed that had already been decided on. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On Mon, 14 Nov 2011 18:47:08 +0900 Bluezery ohpo...@gmail.com said: considering the amount of refactoring.. this will have to wait until after 1.1. we are in feature freeze. that means no refactoring. no new features. just bug fixes. Oh, I see. That's better. :) On Mon, Nov 14, 2011 at 6:10 PM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 10:08:09 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Mon, Nov 14, 2011 at 9:57 AM, Mike Blumenkrantz m...@zentific.com wrote: On Mon, 14 Nov 2011 09:48:07 +0100 Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/14/2011 01:47 AM, Bluezery wrote: This patch is rejected?? or could be in ?? :-) To me it seems fine, but I don't want to commit it now so close before release of 1.1. Either someone how knows ecore_con better than me (Cedric maybe?) can commit it, or I will do it after 1.1 S. I know nothing about the curl stuff or I would have already reviewed it. My vote is also for Cedric. Due to my limited amount of time and my uncertainty about the idler issue. I would prefer that we wait just one week, let 1.1 go and then put your patch in. Yes, I assumed that had already been decided on. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
This patch is rejected?? or could be in ?? :-) On Sat, Nov 12, 2011 at 3:05 AM, Cedric BAIL cedric.b...@free.fr wrote: Yop, On Fri, Nov 11, 2011 at 9:55 AM, Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/11/2011 09:41 AM, Bluezery wrote: It's my mistake. fixed patch is attached again. I have removed active flag also. I use eina_list_data_find() instead. Also, there is used a lot of idlers. I think all idlers can be removed now, as we only do one multi perform on each fd handler ready. The reason the idlers were added, was that we did multi_perform in loop for 0.1s (or something like that) which clogged the system. Cedric was the one adding the idlers, Cedric??? Yup, the idler are here to reschedule the handling of data later so that the UI continue to be responsive even in a storm of data on a slow machine. I think they should be kept around as this will always be the case. -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On 11/11/2011 03:09 AM, Bluezery wrote: Dear all, I have modified the way curl used in ecore_con_url.c Don't need to use both of the free functions. + EINA_LIST_FREE(_url_con_list, con_url) ecore_con_url_free(con_url); + eina_list_free(_url_con_list); -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
It's my mistake.
fixed patch is attached again.
I have removed active flag also.
I use eina_list_data_find() instead.
On Fri, Nov 11, 2011 at 4:54 PM, Sebastian Dransfeld s...@tango.flipp.net
wrote:
On 11/11/2011 03:09 AM, Bluezery wrote:
Dear all,
I have modified the way curl used in ecore_con_url.c
Don't need to use both of the free functions.
+ EINA_LIST_FREE(_url_con_list, con_url)
ecore_con_url_free(con_url);
+ eina_list_free(_url_con_list);
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (리비전 65035)
+++ src/lib/ecore_con/ecore_con_url.c (작업 사본)
@@ -35,8 +35,6 @@ int ECORE_CON_EVENT_URL_COMPLETE = 0;
int ECORE_CON_EVENT_URL_PROGRESS = 0;
#ifdef HAVE_CURL
-static Eina_Bool _ecore_con_url_fd_handler(void *data,
- Ecore_Fd_Handler *fd_handler);
static Eina_Bool _ecore_con_url_perform(Ecore_Con_Url *url_con);
static size_t_ecore_con_url_header_cb(void *ptr,
size_t size,
@@ -57,12 +55,11 @@ static size_t _ecore_con_url_read_cb(voi
void *stream);
static void _ecore_con_event_url_free(void *data __UNUSED__,
void *ev);
-static int _ecore_con_url_process_completed_jobs(
- Ecore_Con_Url *url_con_to_match);
static Eina_Bool _ecore_con_url_idler_handler(void *data);
+static Eina_Bool _ecore_con_url_fd_handler(void *data __UNUSED__, Ecore_Fd_Handler *fd_handler __UNUSED__);
-static Ecore_Idler *_fd_idler_handler = NULL;
static Eina_List *_url_con_list = NULL;
+static Eina_List *_fd_hd_list = NULL;
static CURLM *_curlm = NULL;
static fd_set _current_fd_set;
static int _init_count = 0;
@@ -113,51 +110,30 @@ EAPI int
ecore_con_url_init(void)
{
#ifdef HAVE_CURL
- _init_count++;
+ if (++_init_count 1) return _init_count;
- if (_init_count 1)
- return _init_count;
-
- if (!ECORE_CON_EVENT_URL_DATA)
- {
-ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
-ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
-ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
- }
+ if (!ECORE_CON_EVENT_URL_DATA) ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
+ if (!ECORE_CON_EVENT_URL_COMPLETE) ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
+ if (!ECORE_CON_EVENT_URL_PROGRESS) ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
if (!_curlm)
{
long ms;
-FD_ZERO(_current_fd_set);
-if (curl_global_init(CURL_GLOBAL_ALL))
- {
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
- return 0;
- }
+// curl_global_init() is not thread safe!
+if (curl_global_init(CURL_GLOBAL_ALL)) return --_init_count;
_curlm = curl_multi_init();
-if (!_curlm)
- {
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- _init_count--;
- return 0;
- }
+if (!_curlm) return --_init_count;
curl_multi_timeout(_curlm, ms);
-if (ms = 0)
- ms = 1000;
+if (ms = 0) ms = 100;
-_curl_timeout =
- ecore_timer_add((double)ms / 1000, _ecore_con_url_idler_handler,
- (void *)0xACE);
+_curl_timeout = ecore_timer_add((double)ms / 1000, _ecore_con_url_idler_handler, (void *)0xACE);
ecore_timer_freeze(_curl_timeout);
}
- return 1;
+ return _init_count;
#else
return 0;
#endif
@@ -167,34 +143,38 @@ EAPI int
ecore_con_url_shutdown(void)
{
#ifdef HAVE_CURL
- if (!_init_count)
- return 0;
-
- _init_count--;
-
- if (_init_count != 0)
- return _init_count;
-
- if (_fd_idler_handler)
- ecore_idler_del(_fd_idler_handler);
-
- _fd_idler_handler = NULL;
+ if (_init_count == 0) return 0;
- if (_curl_timeout)
- ecore_timer_del(_curl_timeout);
-
- _curl_timeout = NULL;
-
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- if (_curlm)
+ if (--_init_count == 0)
{
-curl_multi_cleanup(_curlm);
-_curlm = NULL;
- }
+if (_curl_timeout)
+ {
+ ecore_timer_del(_curl_timeout);
+ _curl_timeout = NULL;
+ }
+
+FD_ZERO(_current_fd_set);
+if (_url_con_list)
+{
+
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On 11/11/2011 03:09 AM, Bluezery wrote: Dear all, I have modified the way curl used in ecore_con_url.c 1) A file descriptor of libcurl is not matched to any easy handles. We can get a file descriptor from curl_multi_fdset(), we do not guarantee that it is a socket of easy handle just performed. If libcurl multi handle uses pipeline, the number of file descriptors is just 1 or 2 even though the number of easy handles is numerous. So, I removed the fd, fd_handler, flags from _Ecore_Con_Url structure. 2) There are no routines when return value is CURLM_CALL_MULTI_PERFORM or still_running is above 1. When return value is CURLM_CALL_MULTI_PERFORM, we just do curl_multi_perform() again. (do not curl_multi_fdset() or curl_multi_info_read() ) In addition, there are case that curl_multi_perform() returns CURLM_OK but we cannot get fd and read any information. (e.g., libcurl threaded resolver enabled) In such a case, current _ecore_con_url_perform() returns EINA_FALSE~~!!!. This is a problem. So, I added routines for each case. 3) Error control should be added. It is not controlled when curl_multi_perform() returns error. Please review a attached patch. You should read waht EINA_LIST_FREE does, and clean up list free'ing. Else the patch seems good. S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On 11/11/2011 09:41 AM, Bluezery wrote:
It's my mistake.
fixed patch is attached again.
I have removed active flag also.
I use eina_list_data_find() instead.
+ EINA_LIST_FOREACH_SAFE(_url_con_list, l, ll, url_con)
+ {
+CURLMcode ret;
+Ecore_Con_Event_Url_Complete *e;
+e = calloc(1, sizeof(Ecore_Con_Event_Url_Complete));
+if (e)
+ {
+ e-url_con = url_con;
+ e-status = 0;
+ _url_complete_push_event(ECORE_CON_EVENT_URL_COMPLETE, e);
+ }
+ret = curl_multi_remove_handle(_curlm, url_con-curl_easy);
+if (ret != CURLM_OK) ERR(curl_multi_remove_handle failed: %s,
curl_multi_strerror(ret));
+_url_con_list = eina_list_remove(_url_con_list, url_con);
}
+ eina_list_free(_url_con_list);
+ _url_con_list = NULL;
Why do you use foreach safe, remove elements from list and then free
list? This is EINA_LIST_FREE.
Also, EINA_LIST_FREE sets list to NULL, no need to set to NULL afterwards.
Also no need to check list != NULL before EINA_LIST_FREE
S.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
On 11/11/2011 09:41 AM, Bluezery wrote: It's my mistake. fixed patch is attached again. I have removed active flag also. I use eina_list_data_find() instead. Also, there is used a lot of idlers. I think all idlers can be removed now, as we only do one multi perform on each fd handler ready. The reason the idlers were added, was that we did multi_perform in loop for 0.1s (or something like that) which clogged the system. Cedric was the one adding the idlers, Cedric??? S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
I have done two more things.
Please check attached patch.
I have tested using elm_map. I works well.
1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead.
2) I removed complete idler and use ecore_event_add() directly.
However, ecore_main_fd_handler_del() sometimes give warnnings because
file descriptors cannot be controlled by ecore_con and only curl
controls those internally.
I think it can be ignored
On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfeld s...@tango.flipp.net
wrote:
On 11/11/2011 09:41 AM, Bluezery wrote:
It's my mistake.
fixed patch is attached again.
I have removed active flag also.
I use eina_list_data_find() instead.
Also, there is used a lot of idlers. I think all idlers can be removed
now, as we only do one multi perform on each fd handler ready.
The reason the idlers were added, was that we did multi_perform in loop
for 0.1s (or something like that) which clogged the system.
Cedric was the one adding the idlers, Cedric???
S.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (리비전 65035)
+++ src/lib/ecore_con/ecore_con_url.c (작업 사본)
@@ -35,8 +35,6 @@ int ECORE_CON_EVENT_URL_COMPLETE = 0;
int ECORE_CON_EVENT_URL_PROGRESS = 0;
#ifdef HAVE_CURL
-static Eina_Bool _ecore_con_url_fd_handler(void *data,
- Ecore_Fd_Handler *fd_handler);
static Eina_Bool _ecore_con_url_perform(Ecore_Con_Url *url_con);
static size_t_ecore_con_url_header_cb(void *ptr,
size_t size,
@@ -57,50 +55,17 @@ static size_t _ecore_con_url_read_cb(voi
void *stream);
static void _ecore_con_event_url_free(void *data __UNUSED__,
void *ev);
-static int _ecore_con_url_process_completed_jobs(
- Ecore_Con_Url *url_con_to_match);
static Eina_Bool _ecore_con_url_idler_handler(void *data);
+static Eina_Bool _ecore_con_url_fd_handler(void *data __UNUSED__, Ecore_Fd_Handler *fd_handler __UNUSED__);
-static Ecore_Idler *_fd_idler_handler = NULL;
static Eina_List *_url_con_list = NULL;
+static Eina_List *_fd_hd_list = NULL;
static CURLM *_curlm = NULL;
static fd_set _current_fd_set;
static int _init_count = 0;
static Ecore_Timer *_curl_timeout = NULL;
static Eina_Bool pipelining = EINA_FALSE;
-typedef struct _Ecore_Con_Url_Event Ecore_Con_Url_Event;
-struct _Ecore_Con_Url_Event
-{
- int type;
- void *ev;
-};
-
-static Eina_Bool
-_url_complete_idler_cb(void *data)
-{
- Ecore_Con_Url_Event *lev;
-
- lev = data;
- ecore_event_add(lev-type, lev-ev, _ecore_con_event_url_free, NULL);
- free(lev);
-
- return ECORE_CALLBACK_CANCEL;
-}
-
-static void
-_url_complete_push_event(int type,
- void *ev)
-{
- Ecore_Con_Url_Event *lev;
-
- lev = malloc(sizeof(Ecore_Con_Url_Event));
- lev-type = type;
- lev-ev = ev;
-
- ecore_idler_add(_url_complete_idler_cb, lev);
-}
-
#endif
/**
@@ -113,51 +78,30 @@ EAPI int
ecore_con_url_init(void)
{
#ifdef HAVE_CURL
- _init_count++;
+ if (++_init_count 1) return _init_count;
- if (_init_count 1)
- return _init_count;
-
- if (!ECORE_CON_EVENT_URL_DATA)
- {
-ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
-ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
-ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
- }
+ if (!ECORE_CON_EVENT_URL_DATA) ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
+ if (!ECORE_CON_EVENT_URL_COMPLETE) ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
+ if (!ECORE_CON_EVENT_URL_PROGRESS) ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
if (!_curlm)
{
long ms;
-FD_ZERO(_current_fd_set);
-if (curl_global_init(CURL_GLOBAL_ALL))
- {
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
- return 0;
- }
+// curl_global_init() is not thread safe!
+if (curl_global_init(CURL_GLOBAL_ALL)) return --_init_count;
_curlm = curl_multi_init();
-if (!_curlm)
- {
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- _init_count--;
- return 0;
- }
+if (!_curlm) return --_init_count;
curl_multi_timeout(_curlm, ms);
-if (ms = 0)
- ms = 1000;
+if (ms = 0) ms = 100;
-
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
But do you need the other idler? _ecore_con_url_idler_handler ? Couldn't the fd wakeup just perform curl handling directly? S. On 11/11/2011 11:12 AM, Bluezery wrote: I have done two more things. Please check attached patch. I have tested using elm_map. I works well. 1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead. 2) I removed complete idler and use ecore_event_add() directly. However, ecore_main_fd_handler_del() sometimes give warnnings because file descriptors cannot be controlled by ecore_con and only curl controls those internally. I think it can be ignored On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfelds...@tango.flipp.net wrote: On 11/11/2011 09:41 AM, Bluezery wrote: It's my mistake. fixed patch is attached again. I have removed active flag also. I use eina_list_data_find() instead. Also, there is used a lot of idlers. I think all idlers can be removed now, as we only do one multi perform on each fd handler ready. The reason the idlers were added, was that we did multi_perform in loop for 0.1s (or something like that) which clogged the system. Cedric was the one adding the idlers, Cedric??? S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
_ecore_con_url_idler_handler() is remained because fd is not set when the return value is CURLM_CALL_MULTI_PERFORM. On Fri, Nov 11, 2011 at 7:52 PM, Sebastian Dransfeld s...@tango.flipp.net wrote: But do you need the other idler? _ecore_con_url_idler_handler ? Couldn't the fd wakeup just perform curl handling directly? S. On 11/11/2011 11:12 AM, Bluezery wrote: I have done two more things. Please check attached patch. I have tested using elm_map. I works well. 1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead. 2) I removed complete idler and use ecore_event_add() directly. However, ecore_main_fd_handler_del() sometimes give warnnings because file descriptors cannot be controlled by ecore_con and only curl controls those internally. I think it can be ignored On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfelds...@tango.flipp.net wrote: On 11/11/2011 09:41 AM, Bluezery wrote: It's my mistake. fixed patch is attached again. I have removed active flag also. I use eina_list_data_find() instead. Also, there is used a lot of idlers. I think all idlers can be removed now, as we only do one multi perform on each fd handler ready. The reason the idlers were added, was that we did multi_perform in loop for 0.1s (or something like that) which clogged the system. Cedric was the one adding the idlers, Cedric??? S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][ecore_con] Refactoring curl port
Yop, On Fri, Nov 11, 2011 at 9:55 AM, Sebastian Dransfeld s...@tango.flipp.net wrote: On 11/11/2011 09:41 AM, Bluezery wrote: It's my mistake. fixed patch is attached again. I have removed active flag also. I use eina_list_data_find() instead. Also, there is used a lot of idlers. I think all idlers can be removed now, as we only do one multi perform on each fd handler ready. The reason the idlers were added, was that we did multi_perform in loop for 0.1s (or something like that) which clogged the system. Cedric was the one adding the idlers, Cedric??? Yup, the idler are here to reschedule the handling of data later so that the UI continue to be responsive even in a storm of data on a slow machine. I think they should be kept around as this will always be the case. -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch][ecore_con] Refactoring curl port
Dear all,
I have modified the way curl used in ecore_con_url.c
1) A file descriptor of libcurl is not matched to any easy handles.
We can get a file descriptor from curl_multi_fdset(), we do not
guarantee that it is a socket of easy handle just performed.
If libcurl multi handle uses pipeline, the number of file descriptors
is just 1 or 2 even though the number of easy handles is numerous.
So, I removed the fd, fd_handler, flags from _Ecore_Con_Url structure.
2) There are no routines when return value is CURLM_CALL_MULTI_PERFORM
or still_running is above 1.
When return value is CURLM_CALL_MULTI_PERFORM, we just do
curl_multi_perform() again. (do not curl_multi_fdset() or
curl_multi_info_read() )
In addition, there are case that curl_multi_perform() returns CURLM_OK
but we cannot get fd and read any information. (e.g., libcurl
threaded resolver enabled)
In such a case, current _ecore_con_url_perform() returns
EINA_FALSE~~!!!. This is a problem.
So, I added routines for each case.
3) Error control should be added.
It is not controlled when curl_multi_perform() returns error.
Please review a attached patch.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (리비전 65035)
+++ src/lib/ecore_con/ecore_con_url.c (작업 사본)
@@ -35,8 +35,6 @@ int ECORE_CON_EVENT_URL_COMPLETE = 0;
int ECORE_CON_EVENT_URL_PROGRESS = 0;
#ifdef HAVE_CURL
-static Eina_Bool _ecore_con_url_fd_handler(void *data,
- Ecore_Fd_Handler *fd_handler);
static Eina_Bool _ecore_con_url_perform(Ecore_Con_Url *url_con);
static size_t_ecore_con_url_header_cb(void *ptr,
size_t size,
@@ -57,12 +55,11 @@ static size_t _ecore_con_url_read_cb(voi
void *stream);
static void _ecore_con_event_url_free(void *data __UNUSED__,
void *ev);
-static int _ecore_con_url_process_completed_jobs(
- Ecore_Con_Url *url_con_to_match);
static Eina_Bool _ecore_con_url_idler_handler(void *data);
+static Eina_Bool _ecore_con_url_fd_handler(void *data __UNUSED__, Ecore_Fd_Handler *fd_handler __UNUSED__);
-static Ecore_Idler *_fd_idler_handler = NULL;
static Eina_List *_url_con_list = NULL;
+static Eina_List *_fd_hd_list = NULL;
static CURLM *_curlm = NULL;
static fd_set _current_fd_set;
static int _init_count = 0;
@@ -113,51 +110,30 @@ EAPI int
ecore_con_url_init(void)
{
#ifdef HAVE_CURL
- _init_count++;
+ if (++_init_count 1) return _init_count;
- if (_init_count 1)
- return _init_count;
-
- if (!ECORE_CON_EVENT_URL_DATA)
- {
-ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
-ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
-ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
- }
+ if (!ECORE_CON_EVENT_URL_DATA) ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
+ if (!ECORE_CON_EVENT_URL_COMPLETE) ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
+ if (!ECORE_CON_EVENT_URL_PROGRESS) ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
if (!_curlm)
{
long ms;
-FD_ZERO(_current_fd_set);
-if (curl_global_init(CURL_GLOBAL_ALL))
- {
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
- return 0;
- }
+// curl_global_init() is not thread safe!
+if (curl_global_init(CURL_GLOBAL_ALL)) return --_init_count;
_curlm = curl_multi_init();
-if (!_curlm)
- {
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- _init_count--;
- return 0;
- }
+if (!_curlm) return --_init_count;
curl_multi_timeout(_curlm, ms);
-if (ms = 0)
- ms = 1000;
+if (ms = 0) ms = 100;
-_curl_timeout =
- ecore_timer_add((double)ms / 1000, _ecore_con_url_idler_handler,
- (void *)0xACE);
+_curl_timeout = ecore_timer_add((double)ms / 1000, _ecore_con_url_idler_handler, (void *)0xACE);
ecore_timer_freeze(_curl_timeout);
}
- return 1;
+ return _init_count;
#else
return 0;
#endif
@@ -167,34 +143,40 @@ EAPI int
ecore_con_url_shutdown(void)
{
#ifdef HAVE_CURL
- if (!_init_count)
- return 0;
-
- _init_count--;
-
- if (_init_count != 0)
- return _init_count;
-
- if (_fd_idler_handler)
- ecore_idler_del(_fd_idler_handler);
-
- _fd_idler_handler = NULL;
+ if (_init_count == 0) return 0;
- if (_curl_timeout)
- ecore_timer_del(_curl_timeout);
-
- _curl_timeout = NULL;
-
- while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- if (_curlm)
+ if (--_init_count == 0)
{
-
