On Wed, 22 Jun 2016 20:11:31 -0700 Cedric BAIL <[email protected]> said:
> On Jun 22, 2016 18:28, "Carsten Haitzler" <[email protected]> wrote: > > On Wed, 22 Jun 2016 10:31:54 -0700 Cedric BAIL <[email protected]> said: > > > 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. > > > > my point is that if you want to have promises mapped natively to each > language > > by hand, then c++ has a wait() and nothing maps to that at all and so you > have > > a wait() that does nothing. > > Ah, ok, so as you have likely guessed now, there will be an implementation > of wait done by the c++ binding that will do exactly what is expected by > c++ developers (and implemented in the way I described above). This is one > of the reason to do things manually is to match the language needs and > adapt. > > > C++ devs used to promises/futures in c++ will be > > confused when a feature they expect to work does not. the point of > mapping to > > the native language type for this is to re-use existing knowledge. the > existing > > knowledge doesnt map. it fails e.g. with wait() > > Ok, so if that was your concern,I hope that it is now clear that it will > work and their is no issue at all with it. work how? if efl's promise doesn't do it - then wait in c++ can only just fail and generate exceptions - so the api is there but it always fails. yes- i know that if the work is done within the same thread e.g as async i/o as part of the mainloop waiting will basically deadlock. in theory it can be made to work by pulling it out of the mainloop and into a thread and just talking directly to the thread then via whatever pipe mechanisms etc. exist. so you say you're happy with a wait() that always throws exception in c++? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
