Parrot 3.10.0 "Apple Pi" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 2 December 2011.
01:01 benabik joined
benabik Merry Christmas, #parrot 02:40
sorear hola, benabik 02:53
benabik o/ sorear 02:54
03:37 Psyche^ joined 06:59 schmooster joined 07:36 jsut joined 10:03 mj41 joined 13:06 PacoLinux joined 14:17 jsut_ joined 14:26 lateau joined 14:58 Hunger joined 15:04 bluescreen joined, lateau left 15:57 benabik_ joined 16:09 Hunger joined 18:01 whiteknight joined
whiteknight good afternoon, #parrot 18:31
benabik o/ whiteknight
whiteknight hello benabik
benabik whiteknight: How's your holidays?
whiteknight benabik: I'm very glad the worst of them are over :) 18:33
benabik ouch
18:34 mj41 joined
whiteknight It's been nonstop since we moved in: Moving, unpacking, baking, shopping, wrapping presents, other preparations, etc 18:34
I'm looking forward to just getting into a normal routine 18:35
benabik Moving and Christmas, not a good combination?
whiteknight my wife does a lot of baking for the holiday. She does cookie exchanges with friends, does breads and other stuff for gifts, cookies for family, deserts for various traditional meals, etc 18:40
so the kitchen, which is still not 100% unpacked from the move, is a disaster 18:41
sorear hello whiteknight 18:42
whiteknight hello sorear
benabik whiteknight: Sounds like fun. We did canning for Christmas, our housemates cooked a couple of ducks… Ours was a mess too. It was such a mess, I didn't want to touch it, but it cleaned up much faster than I expected. 18:48
whiteknight ooh, what did you can? I've been wanting to do some canning this year myself 18:49
benabik Apple butter and BBQ sauce. 18:50
The apples took forever to simmer down. Oy.
And we had to do a ton of the BBQ.
whiteknight your own BBQ sauce recipe?
benabik We had to be careful what recipes we used because we don't have a pressure cooker. They have to be pretty acidic if you're going to just use a water bath. 18:51
My wife found it online somewhere… I might still have the link...
www.theyummylife.com/blog/2011/01/1...,+or+Smoky
whiteknight nice 18:52
I always find that little homemade food gifts go over very well and can be very cheap to make in bulk 18:53
benabik We haven't had time to try it out on a full meal, but the little tastes we had were gooood.
Cheap in money, but the extra time it takes can be a real pain. ;-)
whiteknight yes, hence why our december has been so crazy 18:54
benabik I think the apple butter recipe is something like this: simplyrecipes.com/recipes/apple_butter/ 18:55
No actual butter, just apples simmered for hours. Pretty tasty.
We tend to use the handmade things to fill out the piles of aunts and uncles on the list. It seems to have gone over pretty well and keep the gift budget from killing the poor grad student. ;-) 18:56
whiteknight I'm a big fan of apple butter, and we usually have extra apples because we like to go out picking in the fall 18:57
my kid loves it, and I bake a mean pie with the results
applebutter would be a nice thing to do also
benabik The canning itself is pretty simple, although you do need to be careful with sanitation. 19:01
whiteknight oh yeah, I've done that before 19:12
benabik Wife is home from boxing day. Good luck with the cleanup, whiteknight 19:13
whiteknight thanks! 19:14
msg alvis are you on a 32-bit or 64-bit machine? I suspect the random number generator behaves differently on each 19:38
aloha OK. I'll deliver the message.
ruoso whiteknight: if you have some time, there are some things regarding threads/concurrency I'd like to discudss 19:45
whiteknight ruoso: for you, for that topic, I always have time :)
ruoso: I saw your email about autothreading pipes. I do think we are definitely moving in that direction 19:47
Your idea about blocked buffer streams sounds interesting, but I don't think I understand all the details 19:49
ruoso Ok, basically this comes from one thing in Perl 19:52
*Perl 6
which is the implicit threading
basically, even if the language ends up providing threading primitives 19:53
most of the concurrency in the language will be provided by implicit threading operations
i.e. every lazy list operation is potentially concurren
*concurrent
whiteknight okay, in what sense? Like the values can be pre-computed? 19:54
ruoso yes
like... my @a = grep { $_ % 2 }, 1..inf;
this will not fail... it will become a lazy list generator 19:55
whiteknight right
ruoso but itś
but it's not completely lazy
it's "mostly lazy"
which means the interpreter is allowed to start producing values as pleased...
and the interpreter is also allowed to do that concurrently with the main program 19:56
so the main program will continue immediately, and a new task (i use task in the parrot sense here)
whiteknight Okay, here's the problem I have. If we move processing over to a separate OS thread, there will be additional overhead associated with moving the data, synchronizing, etc
if we do it in a Task on the current thread, we basically cut processing bandwidth for the "master" task 19:57
so if we start using the value immediately, we don't want to have synchronized and gone through lock headaches on a separate thread
ruoso but... in the simple case above, why would you need locks? 19:58
whiteknight not just locks. Maybe no locks at all. Still, if we're operating on data on a separate thread we need some kind of synchronization
ruoso why?
I mean... 19:59
whiteknight you need to be able to guarantee thread-safe reads on complex aggregate data
ruoso you have the stream that will work as sync agent
whiteknight ok
ruoso the user is not supposed to change data that was already sent on a stream 20:00
if he does that, he is the one to blame
whiteknight "not supposed to" or "not allowed to"?
ruoso we don't need to protect against that
whiteknight ok
ruoso we could just say 'doing that results in undefined behavior'
whiteknight My only real concern is that any threading is going to add some amount of overhead. If we cut consistency measures down to the bare minimum, we still have some overhead 20:01
so some common use-cases could end up operating slower if we get threads involved
if the compiler is smart enough to weed those cases out, that's cool too 20:02
ruoso Yes...
a simple @a = grep { $_ % 2 } 1..10; is clearly not worth for lazyness
this is something the compiler is responsible to detect
the compiler or the runtime... 20:03
whiteknight Okay, that concern is covered. So how do we implement these buffered streams like you're talking about?
ruoso circular queue
just like unix pipes 20:04
whiteknight you're not worried about losing data?
or do you put in write-stops to halt the stream source when the queue is full?
ruoso I am... that's why it's blocking
whiteknight okay, gotcha
ruoso and if it's done in the VM level, it can simply change the status of the task to Blocked and the scheduler will know what to do 20:05
whiteknight so basically like a mailbox, in reverse. Reading from the Task instead of writing to it 20:06
Yeah, I think we can do that
nine: ping
ruoso it's a pipe, really
in the my @a = grep { $_ % 2 } 1..inf; example 20:07
it would initiate two tasks
1 producing the range
2nd computing the grep closure
the first would use a stream to send data to the second
the second would use a stream that would be used to populate @a (whenever someone actually reads a value) 20:08
so the second stream would fill very quickly, blocking the second task, then filling the first stream and blocking the first task
at the moment someone did @a.shift, it would create some room in the second buffer, which would unblock the second task, which would consume from the first stream, unblocking the first task... 20:09
whiteknight okay, I see what you are saying 20:15
so this is something we would have to integrate into the concurrency system pretty closely, if it wants to have reasonable control over the Task 20:16
ruoso Yes... it would be a primitive preemptiveness control 20:17
(just like unix pipes...)
whiteknight I'm not entirely familiar with how unix pipes work internally. 20:18
ruoso they are blocking streams
at the kernel level 20:19
simple as that
whiteknight So I'm trying to work out the implementation in my head. Do we want a stream type, or add stream logic to all tasks?
ruoso a stream type, I would thikn
whiteknight I assume the former, but I might not know what the most common use-case for Tasks is going to be
ruoso in the unix world, a pipe will work by two file descriptors 20:20
from/to you read/write to/from
so a pipe is really a buffer 20:21
and then you have one read handle and one write handle to that buffer
whiteknight so the Stream would hold a Task reference. When the stream is read it blocks the reader, activates the source until it has a few values?
then it blocks the source when the stream is full?
ruoso Yes. 20:22
whiteknight until it's empty again, then it activates the source again, repeat
okay, I like that
ruoso not empty...
it's concurrent
whiteknight what do you mean?
ruoso the reader unblocks as soon as there is anything in the buffer
the writer unblocks as soon as there is any room in the buffer
basically the buffer has "file descriptors" associated with it. The file descriptor belongs to a process 20:23
the read process is awaken when there are contents in the buffer 20:24
the write process is awaken when there is enough room for a write in the buffer
whiteknight so the buffer always wants to be full? That seems a little bit eager
ruoso Yes, the buffer always wants to be full... 20:25
whiteknight In terms of performance, I feel like we would want to calculate data on demand instead of over-calculating
but that's a semantic issue that we can change trivially
ruoso and that can even be set at runtime
whiteknight I *suspect* a "fill when empty" rule would have better performance overall
ruoso if in the end it's IO bound, the "always full" will probably be better 20:26
but my point is that it should probably be left to runtime decision 20:27
(even if that means a pragma, or a command line argument)
I don't know how Parrot handles IO, but my suggestion would be to emulate the way file descriptors are handled and use the same APIs 20:31
with the exception that it wouldn't be a system call, but rather a VM-call
I assume you have to handle that with the green threads and system "read" calls 20:32
whiteknight In the new thread system, we're going to be moving towards VM calls for IO instead of direct system calls 20:33
ruoso that's perfect
so this would be an emulation of unix pipes 20:34
whiteknight we'll probably have a dedicated worker thread at some point for it (for systems which support it). AIO will be the default mode of operation and blocking calls will be AIO+Task Sleeps
of course, dedicated read sources might be their own thread or something 20:35
We don't have threads yet, so we can really do anything at this point 20:37
ruoso well... you do have the green threads already, don't you?
I don't think you need real threads to implement that primitives 20:38
whiteknight no, you're right. I'm just saying that there is lots of behavior decisions which are still up in the air 20:41
(if you have any other recommendations as they pertain to perl6, that would be great)
ruoso I think it's a good thing we leave as much of that as possible to runtime 20:42
the only settled down threading operative in Perl 6 is "async" so far... 20:44
which is not even spec'ed to be a OS thread
it's just "async"
20:46 mj41 joined
ruoso So... if we were to think about "types", I would think: "Feed", "Feed Handle". A Feed may have several handles associated with it. A "Feed Handle" may be a read or a write handle and belongs to one task. The "Feed Handle" would also keep a status indicating if it is trying to read/write. 20:47
whenever availability changed in a "Feed", the associated handles would be searched for to see if anyone was blocked on it... changing the status of the associated task in that case. 20:48
whiteknight I'm not sure I see the value in having two types. A Feed would be it's own handle, no?
ruoso A feed is global, a feed handle belongs to a task
the handles can be closed asynchronously... 20:49
if the read side closes the handle... it needs to raise an exception in the write side 20:50
a.k.a. SIGPIPE
and also, when all handles are closed, the feed can be destroyed 20:52
Also, you may have more then one read handle per feed 20:53
if different tasks cooperatively consume one input feed
whiteknight we don't really need that. Parrot has GC, a reference to the Feed is enough to keep the feed alive
and when there are no references, GC makes it dead
ruoso sure... that's what I meant 20:54
whiteknight if the read-side closes, do we throw an exception on the write side, or just tell the writer to block?
I mean, an exception seems heavy-weight to me
ruoso well... if there is no one else to read 20:56
the write side needs to be interrupterd
*interrupted 20:57
note that the feed itself is only addressable by its handles
so once you close all read handles, there is no way to get a new read handle
(addressable by the tasks, that is... the vm is the only thing holding a reference to the actual buffer 20:59
21:04 particle joined 21:19 particle joined 22:54 mj41 joined 22:59 jsut joined 23:59 contingencyplan joined, schmooster joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!