On Tue, Mar 4, 2008 at 12:36 PM, Elf <address@hidden> wrote:
try putting a (thread-yield!) and it works in readline.
Yeah you're right.
csi> (use srfi-18)
; loading library srfi-18 ...
csi> (thread-start! (lambda () (let loop () (printf "loop~%")
(thread-yield!) (loop))))
#<thread: thread0>
csi> (thread-yield!)
loop
csi> (thread-yield!)
loop
Well I'm working on the dbus egg, and as it turns out there needs to
be a polling loop to receive incoming dbus messages. So I was hoping
to hide the polling loop inside the egg, but maybe there will be some
problems with that. I wanted to make it possible to register a
function (assign it to some combination of
service/path/interface/method-name) as a callback, so it will be
called when the matching message is received, rather than leaving it
up to the user of the egg to "pull" the messages out and dispatch
them, or ask them to be dispatched. So if you write a multi-threaded
app, or call thread-yield! periodically, the threaded callback model
could work, but it's unfortunate to require that kind of design, or
else expose the necessity of doing the polling yourself.
I sure wish Chicken had real threads. (Yes I know it's next to
impossible.) The excuse I tell myself for accepting that limitation
is that maybe when SMP gives way to grid-style computing, when each
core has its own memory, then a multi-process model for computing
makes more sense. Fortunately SRFI-18 threads do not block on TCP
sockets, so there you go, parallel computing is possible, and I should
just use processes rather than threads, keep it coarse-grained, and
eat the cost of doing the messaging (as opposed to sharing memory).
But that doesn't help in this case, because the dbus egg is just a
nice interface to an IPC mechanism, which doesn't inherently have the
need to block as long as it's based on sockets (which it might not
always be).
Well I guess I'll have to have stuff like
dbus:peek-next-message
dbus:next-message
dbus:dispatch-next-message
dbus:dispatch-loop
and then the user of the egg has the choice: wrap the dispatch-loop
call in a thread and callbacks happen automatically as long as nothing
else blocks, poll manually but still have callbacks, or poll manually
and examine the messages manually too. Anybody have a better idea?
_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users