On Tue, 11 May 2004, Uri Guttman wrote:
Why would alarm need any special opcode when it is just a timer
with a delay of [abs_time minus NOW]?
Let the coder handle that and lose the extra opcodes.
mab you want to make the latency between getting the abs_time, doing
mab the
At 6:54 PM +1200 6/15/04, [EMAIL PROTECTED] wrote:
On Tue, 11 May 2004, Uri Guttman wrote:
Why would alarm need any special opcode when it is just a timer
with a delay of [abs_time minus NOW]?
Let the coder handle that and lose the extra opcodes.
mab you want to make the latency
On Tue, May 11, 2004 at 02:06:51PM -0400, Dan Sugalski wrote:
At 1:10 PM -0400 5/11/04, Uri Guttman wrote:
i don't think there is a need for all those variants. why would alarm
need any special opcode when it is just a timer with a delay of abs_time
- NOW? let the coder handle that and lose
Uri Guttman [EMAIL PROTECTED] wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Because of this, you have the event PMC for a Named event before the
DS event occurs and thus can wait on it. You *don't* have the event PMC
DS for an anonymous event, so you can't wait on it, all you can
Uri Guttman [EMAIL PROTECTED] wrote:
settimer Pevent, Idelay_seconds, Iinterval_seconds[, Pcallback,
Puserdata]
so now all you have is two signatures (for float or integer seconds).
No. Above Csetttimer definition expands to 8 different functions for
INTVAL arguments only:
You wrote:
i don't think there is a need for all those variants. why would alarm
need any special opcode when it is just a timer with a delay of abs_time
- NOW? let the coder handle that and lose the extra op codes.
No, you don't want to do it that way. Becasue you want to make the latency
At 2:59 PM -0400 5/11/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
chromatic wrote:
So for SDL, I'd start a separate thread that blocks on
SDL_WaitEvent,
creating and posting events when they happen. My main program would
handle the events as normal Parrot events. Standard producer
At 2:47 PM -0400 5/11/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
At 10:33 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
I'm also curious how to write an interface to an
existing event system.
Being able to write it all in PASM is a bonus.
On May 12, 2004, at 09.12, Dan Sugalski wrote:
At 2:59 PM -0400 5/11/04, Gordon Henriksen wrote:
As I pointed out in another post, this doesn't work for integrating
with at least two significant event sources: Windows and the Mac
OS. :) UI events need to be handled synchronously on the thread
At 12:14 PM -0700 5/11/04, Dave Whipp wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
The terminology there's a bit strained, and I think it's in large
part responsible for most of the rest of the confusion.
They're probably better called Named and Anonymous events, though
that's a bit dodgy in
Gordon Henriksen wrote:
Oh, it's worse than thatGUI commands need to be issued from the main
thread, at least with OS X. (There's no actual requirement as to which
thread handles the actual events as long as you treat the OS event
queue as the thread-unsafe thing it seems to be) Or so the docs
At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
Uri Guttman [EMAIL PROTECTED] wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Because of this, you have the event PMC for a Named event before the
DS event occurs and thus can wait on it. You *don't* have the event PMC
DS for an
Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
$SIG{CHLD} = sub { 1; };
This could probably create the event PMC, associate the user callback
with it, enable SIGCHLD and be done with it. It's the same as with a
timer event.
Which is swell, except
At 8:02 PM +0200 5/12/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
$SIG{CHLD} = sub { 1; };
This could probably create the event PMC, associate the user callback
with it, enable SIGCHLD and be done with it. It's the same as
Brent 'Dax' Royal-Gordon wrote:
Gordon Henriksen wrote:
Oh, it's worse than that—GUI commands need to be issued
from the main
thread, at least with OS X. (There's no actual requirement
as to which
thread handles the actual events as long as you treat the OS event
queue as the
Dan Sugalski [EMAIL PROTECTED] wrote:
I know that. The current scheme is safe WRT these problems. A signal
originates from the signal handler, incrementing a sig_atomic_t variable
per signal.
That doesn't work.
??? It's one of the few safe actions what you can do in an interrupt
handler. WTF
Dan Sugalski [EMAIL PROTECTED] wrote:
None of this is set in stone, but take a look and see how everyone feels
about this.
I'll get to IO after, since the two are pretty tightly intertwined, and
changes to this will affect the IO stuff too.
Snip here---
Events,
None of this is set in stone, but take a look and see how everyone feels
about this.
I'll get to IO after, since the two are pretty tightly intertwined, and
changes to this will affect the IO stuff too.
Snip here---
Events, another design sketch
Overview
Events
One quick point: unless I'm misunderstanding something, there seems to
be no easy way to wait on multiple events to complete if those events
can occur in any order. For instance, suppose we have 5 events, P1 - P5
If we know that the events will occur in some specified order (say
1-2-3-4-5),
At 12:20 PM -0400 5/11/04, Simon Glover wrote:
One quick point: unless I'm misunderstanding something, there seems to
be no easy way to wait on multiple events to complete if those events
can occur in any order. For instance, suppose we have 5 events, P1 - P5
If we know that the events will
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Event Classes
DS =
DS There are two main classes of events, which we'll call expected and
DS unexpected.
DS An expected event is one that your program is specifically expecting
DS to get as a result of a request for
On Tue, 2004-05-11 at 09:44, Dan Sugalski wrote:
Thinking we might want:
waitall Parray_of_events
waitany Parray_of_events
?
I certainly do!
I'm also curious how to write an interface to an existing event system.
Being able to write it all in PASM is a bonus.
-- c
SG == Simon Glover [EMAIL PROTECTED] writes:
SG One quick point: unless I'm misunderstanding something, there seems to
SG be no easy way to wait on multiple events to complete if those events
SG can occur in any order. For instance, suppose we have 5 events, P1 - P5
SG If we know
At 10:09 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 09:44, Dan Sugalski wrote:
Thinking we might want:
waitall Parray_of_events
waitany Parray_of_events
?
I certainly do!
Fair enough.
I'm also curious how to write an interface to an existing event system.
Being able to
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
I'm also curious how to write an interface to an existing event system.
Being able to write it all in PASM is a bonus.
I don't think it can be all-PASM, except maybe (and maybe not...)
with a separate thread for the existing event source. To
At 10:33 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
I'm also curious how to write an interface to an existing event system.
Being able to write it all in PASM is a bonus.
I don't think it can be all-PASM, except maybe (and maybe not...)
with a separate
c == chromatic [EMAIL PROTECTED] writes:
c On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
I'm also curious how to write an interface to an existing event system.
Being able to write it all in PASM is a bonus.
I don't think it can be all-PASM, except maybe (and maybe not...)
At 1:10 PM -0400 5/11/04, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Event Classes
DS =
DS There are two main classes of events, which we'll call expected and
DS unexpected.
DS An expected event is one that your program is specifically expecting
On Tue, 2004-05-11 at 10:45, Dan Sugalski wrote:
That'll still need some C. The event system as it stands is all
active--all event sources put events into the system, rather than
having the event system go looking at event sources for events. You'd
either need to queue up regular timer
At 11:18 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:45, Dan Sugalski wrote:
That'll still need some C. The event system as it stands is all
active--all event sources put events into the system, rather than
having the event system go looking at event sources for events. You'd
On Tue, 2004-05-11 at 11:23, Dan Sugalski wrote:
Since it's blocking, it won't eat up too many resources -- that's nice.
It'd be nice to have the SDL event thread ignore events I don't care
about though, instead of creating event PMCs I'll just throw away later.
You can always Get Horribly
Dan Sugalski wrote:
At 10:33 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
I'm also curious how to write an interface to an
existing event system.
Being able to write it all in PASM is a bonus.
I don't think it can be all-PASM, except maybe
Dan Sugalski wrote:
chromatic wrote:
So for SDL, I'd start a separate thread that blocks on
SDL_WaitEvent,
creating and posting events when they happen. My main program would
handle the events as normal Parrot events. Standard producer
consumer
stuff.
Since it's blocking, it
DS == Dan Sugalski [EMAIL PROTECTED] writes:
i disagree with the two classes. how can you handle an unexpected event
without know it could happen? effectively all events are expected, some
are more expected than others. :)
DS The terminology there's a bit strained, and I think it's
mab == mark a biggar [EMAIL PROTECTED] writes:
mab You wrote:
i don't think there is a need for all those variants. why would alarm
need any special opcode when it is just a timer with a delay of abs_time
- NOW? let the coder handle that and lose the extra op codes.
mab No, you
35 matches
Mail list logo
