On Tue, Jun 21, 2016 at 10:35 PM, Carsten Haitzler <[email protected]> wrote: > On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL <[email protected]> said: >> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler <[email protected]> >> wrote: >> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida >> > <[email protected]> said: >> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler <[email protected]> >> >> wrote: >> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida >> >> > <[email protected]> said: >> >> > >> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler >> >> >> <[email protected]> >> >> >> wrote: >> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida >> >> >> > <[email protected]> said: >> >> >> >> [snip] >> >> >> >> >> There will be wait. I'll implement it. It will throw an exception if it >> >> >> is called from the mainloop thread. And people will miss cancel if they >> >> >> don't look for it. They will miss it too if they use Eo_Promise too and >> >> >> don't look for it. >> >> > >> >> > there';s a difference. if it's a std promise then they expect it to work >> >> > a certain way. if its an efl one they need to learn its api and >> >> > behaviour. they will find the features. >> >> >> >> We can't be arguing C++ API because users won't read a header file. >> >> This is not reasonable. Do we expect C developers to read >> >> documentation, or at least doxygen docs? >> > >> > we do expect them to read. though in my experience few actually read a >> > header file. docs is an expectation. >> > >> > but the issue here is of masquerading with a feature that will never work >> > (wait). it'll always cause an exception. it'd just be best to look similar >> > to a future/promise and just be a different class. >> >> I don't understand why you think we can't implement wait. The C++ >> standard doesn't expect it to work with a mainloop, but from another >> thread. So it is very simple to implement it. When you instanciate a >> promise, you do also create a mutex, a cond and add a first >> then/cancel couple that will just take that mutex, set the value and >> broadcast on the cond. The future itself when instanciated will ref >> count the promise and on the wait will take the mutex and wait on the >> cond if the value is not there already. The only difference is that >> use of wait in C++ will lead to dead lock if you use it in the same >> thread, we will have a warning and throw an excepion in that case. >> This is the only difference and I fail to see where you see a problem. > > we have no wait in efl for promises. that's my point. it doesn't exist. and > yes > - if it were to be used within the same thread where the work is done - it'd > deadlock.
Yes, we don't have one and it would only make sense to have one, when we push for having more thread around, for now it can wait. And if it is possible to implement it in the C++ binding, it should be possible in C when the need come. I still don't get why you are making that point. The C++ binding as any binding on promise is manually done for reason discussed in other email here, so the fact that we do not have a 1:1 matching doesn't matter as long as we can provide what the user of that language expect, which we can. -- Cedric BAIL ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
