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 lat
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
> ma
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 an
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
handle
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
> >>
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
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 swel
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
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 thread-unsafe thing it seems to be) Or so the docs
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 i
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 t
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
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
c
"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 some ways too. Maybe specific and gen
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
bet
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 C definition expands to 8 different functions for
INTVAL arguments only:
Parrot
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 o
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<---
> Eve
> "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.
> "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
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 blo
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-P
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 Ho
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
ei
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 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 e
> "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 (an
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
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 sour
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 wri
> "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
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
> "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 requ
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 occ
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), t
35 matches
Mail list logo
