sorry, i phrased that really poorly. what i meant was, they seem to be intended as a kind of "everything included" replacement for multiple threading. for example, the PR you link to adds channels.
i assumed that was why they have a reputation for being too slow to be useful in cases where, say, you can just allocate an array, fill it in a loop, and return the array. or am i wrong about that too? maybe it would be clearer if i explained a motivating example. i recently wrote a parser combinator using a trampoline approach. obviously, i could have used Tasks to simplify the code. but i didn't because i assumed they would be way slower than doing the trampoline by hand. now i don't have a reference for that, but the comments earlier in this thread say that they are type unstable, which would certainly not help. so what i am asking, i guess is: (1) am i wrong about Tasks being slow? (2) if not, are there any plans for a faster, simpler, type-stable coroutine? (3) or even just lazy streams, if that helps with type stability? andrew On Tuesday, 7 July 2015 10:02:20 UTC-3, Amit Murthy wrote: > > Tasks are lighweight, not at all like threads. You can literally have > thousands of them without any issues. Multi-threaded julia is a > work-in-progress. Currently each julia process has a single thread of > execution and tasks switch whenever there is I/O involved or on an explicit > yield(). libuv provides the underlying event-driven I/O, timers, etc. > > On Tue, Jul 7, 2015 at 6:02 PM, andrew cooke <[email protected] > <javascript:>> wrote: > >> >> it seems to me that coroutines (Tasks) in julia are very much intended >> for "heavyweight" multithread use. >> >> but lazy streams are really useful in general (they transformed how i use >> python), and even full-on coroutines can be useful in some single-threaded >> applications. so i wonder if there's a need for a lighter-weight >> implementation? maybe something already exists - it's not clear to me this >> needs to be part of the base language. >> >> andrew >> > >
