The API documentation says *Returns:*1 or greater on success, 0 otherwise
The API behaviour should be consistent with the above. Regards, Sanjeev On Fri, May 18, 2012 at 11:20 AM, ChunEon Park <[email protected]> wrote: > > Regardless with user's mistake, > The case, under 0 initialization time, is nonsense and unacceptable. > > > We can prevent this kind of idiotic case. > > > ------------------------------------ > > -Regards, Hermet- > > > > -----Original Message----- > From: "Bluezery"<[email protected]> > To: "Jonas M. Gastal"<[email protected]>; "Enlightenment > developer list"<[email protected]>; > Cc: > Sent: 2012-05-18 (금) 10:55:13 > Subject: Re: [E-devel] Questions about initilization functions such as > elm_init() and ecore_init(), etc. > > 2012/5/18 Jonas M. Gastal <jgastal>@profusion.mobi>: > > On Thursday 17 May 2012 23:51:34 Bluezery wrote: > >> Dear EFL developers, > >> > >> I have questions about initialization/unintialization functions > in EFL > >> such as elm_init(), ecore_init(), elm_shutdown(), etc. > >> Those functions have interval static counter variables such as > >> _ecore_init_count. > >> And If xxx_init() is called, a counter variable increases by 1 > and if > >> xxx_shutdown() is called, it decreases. > >> However, I think that those confuse users (application > developers) somewhat. > >> > >> For example, if ecore_shutdown() is called twice and ecore_init() > is > >> called once after that, nothing is initialized. > >> Because after _ecore_init_count variable become 1, ecore_init() do > >> evil_init() or eina_init(), etc. > >> It seems that ecore_init() should be called 3 times after > >> ecore_shutdown() is called twice. All other xxx_init, > xxx_shutdown() > >> pairs in EFL do same behavior. > >> IMHO, After ecore_shutdown() is called many times, calling > >> ecore_init() once should do initialization. > >> Of course, If ecore_init() is called 10 times, ecore_shutdown() > >> should do unintialization at the moment ecore_shutdown() is > called 11 > >> time. > >> > >> Also return value is somewhat confusing. In documentation of > >> ecore_init() and ecore_shutdown(), It succeed if return value is > 1 and > >> it fail if it is 0. > >> But it returns static counter variable. This may need > documentation > >> modification in ecore. And other xxx_init() and xxx_shutdown() are > >> better to have same pattern. > >> > >> Please solve my curiosity :) > >> Thanks. > > > > Bluezery, > > > > Calling xxx_shutdown() when xxx is not initialized is a program > error, the EFL > > could handle this particular issue, but there too many ways the > programmer can > > make mistakes, handling everyone of them would be very hard and have a > > considerable performance cost. > > Thank you for comments. > I agreed that handling user's mistakes are harsh. > But It need to check _ecore_init_count should not be below 0. (it > should not be a negative number.) > If so, calling ecore_shutdown() before ecore_init() can be no problem. > > > The way to use the xxx_init() and xxx_shutdown() functions is to call > init > > once for each library you use in the beggining of your main function > and to > > call shutdown once for each library you initialized. When creating > > applications you don't need to worry about it being reference counted > or > > anything like that, init once, shutdown once, for each lib. > > > > With regards to the documentation, it looks right to me. For > ecore_init() it > > says: "1 or greater on success, 0 otherwise" which is the value the > reference > > counting variable will have, 1 or greater if the library was actually > > initialized, 0 otherwise. For ecore_shutdown() we're actually missing > the > > explanation of the return value(will add as soon as I'm done writing > this =), > > it's return value will be 1 or greater if the library is still > running, 0 > > otherwise. But the return value of ecore_shutdown(), and other > _shutdown() > > functions, is not something the application developer has to care > about, for > > _init() it matter because you need to do error checking, for shutdown > though > > just call it, if the value returned is greater than one, it just > means there's > > something else still using, not a problem if you remembered to pair > every > > _init() with a _shutdown(). > > The example I suggested above shows that ecore_init() succeed even if > ecore_init() returns a negavie number (-1 or -2, ...). But it's > actually originated from user's mistake. (calling ecore_shutdonw > before ecore_init). Does there need some explanations in documentation > if EFL do not handle this issue? :) > > > > > Hope this clarifies the issue some. > > > > Gastal > > -- > BRs, > Kim. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
