# New Ticket Created by chromatic
# Please include the string: [perl #51870]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51870 >
Currently, the concurrency and events system only handles pending events at
speci
Fixed website to point to non-draft location.
On Oct 16, 2007, at 3:36 AM, Allison Randal wrote:
I've just launched PDD 24 out of the draft directory. Comments and
suggestions welcome.
Allison
--
Will "Coke" Coleda
[EMAIL PROTECTED]
I've just launched PDD 24 out of the draft directory. Comments and
suggestions welcome.
Allison
Nicholas Clark wrote:
What is the state of signals and events support? As far as I can tell from
watching which perl 5 regression tests fail or hang under parrot, currently
parrot can't behave as a passive embedding target - it assumes that it needs
to take ownership of all signals.
P
What is the state of signals and events support? As far as I can tell from
watching which perl 5 regression tests fail or hang under parrot, currently
parrot can't behave as a passive embedding target - it assumes that it needs
to take ownership of all signals.
Is this likely to change
> Parrot's locks will all have wait/signal/broadcast capabilities. We
> should go rename the macros and rejig the code. This may have to wait
Really? I'm not sure I understand what broadcast does on a lock. Are
you talking about something like P5's condpair? If so, why not just
cop that code? Of c
At 8:42 AM -0500 11/19/04, Gabe Schaffer wrote:
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
The problem is a different one: the COND_INIT macro just passes a
condition location, the mutex is created in a second step, whi
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> The problem is a different one: the COND_INIT macro just passes a
> condition location, the mutex is created in a second step, which isn't
> needed for windows. OTOH a mutex a
. Actual EventDispatch() would be a generic
function that puts an event into a thread's queue and notifies the
thread. I am not sure how to handle general events like RunGC.
* GUI message handlers need to dispatch events synchronously. So the
generic check_events function would call X
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
>> >> Not quite. COND_WAIT takes an opaque type defined by the platform, that
>> >> happens to be a mutex for the pthreads based implementation.
>>
>> > It should, but it doesn't. Here's the definition:
>> > # define COND_WAIT(c,m) pthread_cond_wait(&c, &m)
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> Yes, there has to be a separate thread to get signals, and each thread
> needs its own event queue, but why does the process have a global
> event_queue? I suppose there are generic events that could be handled
> just by the n
roadcast
> a condition or something.
> So I came up with that experimental code of one thread doing signals.
Yes, there has to be a separate thread to get signals, and each thread
needs its own event queue, but why does the process have a global
event_queue? I suppose there are generic e
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
>> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32
>> >
On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32
> > condition variables (called "events") are kernel object
, but Win32
condition variables (called "events") are kernel objects that do not
require any other object to be associated with them. I think this
could be cleaned up with further abstraction.
Not quite. COND_WAIT takes an opaque type defined by the platform, that
happens to be a mutex f
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> I was just browsing the Parrot source, and noticed that the threading
> implementation is a bit Unix/pthread-centric. For example:
> * COND_WAIT takes a mutex because that's how pthreads works, but Win32
> condition variables (call
I was just browsing the Parrot source, and noticed that the threading
implementation is a bit Unix/pthread-centric. For example:
* COND_WAIT takes a mutex because that's how pthreads works, but Win32
condition variables (called "events") are kernel objects that do not
require any
# New Ticket Created by Will Coleda
# Please include the string: [perl #31651]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31651 >
(No details. This comes from TODO.win32)
On Fri, 2004-05-14 at 06:27, Rachwal Waldemar-AWR001 wrote:
> It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot
> event'?
> One advantage... it'd be easy searchable. I recall a pain whenever I searched for
> 'thread', or 'Icon'.
If you're talking about search engine
Butler, Gerald wrote:
> How about: "tocsin"
[...thinking out loud...]
I'm not sure it's a good idea to use an obscure word, even if it is
appropriate to the usage. It should be a word that the average user
would recognise, and hopefully be able to intuit some sense of what it
does.
How about "P
I LOVE IT: "PARrot Container for Event Lobbing!!!"
-Original Message-
From: Andy Wardley [mailto:[EMAIL PROTECTED]
Sent: Friday, May 14, 2004 7:36 AM
To: Butler, Gerald
Cc: 'Gordon Henriksen'; '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 6:08 PM
To: [EMAIL PROTECTED]
Subject: Events (I think we need a new name)
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a sec
TECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Events (I think we need a new name)
Matt Fowles wrote:
> I think Page already has a different meaning in computers,
> namely a page of memory.
Not to mention a web page.
> For what it is worth, I support event as the name.
Being as I think I'm
On Wed, May 12, 2004 at 06:15:54PM +0200, K Stol wrote:
| >It does, though, sound like we might want an alternate name for this
| >stuff. While event is the right thing in some places it isn't in
| >others (like the whole attribute/property mess) we may be well-served
| >choosing another name. I
On 12 May 2004, at 17:38, Brent 'Dax' Royal-Gordon wrote:
It's Parrot telling you that something happened.
Squawk?
Mike
I should point out that I do actually support
calling these events--so long as they're modified to play nice with OS
event loops. Upon reflection, that just requires a means to
synchronously dispatch an event to a handler chain from a C callback.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
All~
I think Page already has a different meaning in computers, namely a page
of memory. This one might be going to far afield for names. For what it
is worth, I support event as the name.
Matt
James Mastros wrote:
Dan Sugalski wrote:
Okay, so I'm working on redoing the events doc
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the
On Wed, May 12, 2004 at 12:08:08PM -0400, Dan Sugalski wrote:
> Okay, so I'm working on redoing the events document based on the
> critiques from folks so far. (Which have been quite helpful) I should
> have a second draft of the thing soon.
>
> It does, though, sound l
er name. I'm open to suggestions here...
How about "skippy"?
Seriously, I would say that event is about as abstract as it comes. Even
the proposed "message" is, in some ways, LESS abstract.
What's the specific sort of case events don't seem to cover? The setting
Dan Sugalski wrote:
> It does, though, sound like we might want an alternate name for this
> stuff. While event is the right thing in some places it isn't in others
> (like the whole attribute/property mess) we may be well-served choosing
> another name. I'm open to suggestions here...
>
incid
ice? (Too similar to 'notification'?)
Message? (Don't really like it, and the term's loaded by ObjC, etc.)
Announcement?
Really, though, these sound like events to me. It's Parrot telling you
that something happened. That's an event in my mind.
--
Brent "D
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event i
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the right thing in
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Or just issue a generic process_events op and spin through the events
DS> in the event queue forevermore. :)
i love spinning the cpu. idle loops are your friend! :)
>> if you set the call
ack to issue a
DS> write for read requests and a read for write requests, and make things
DS> specific.
but then you still need the main line of code to block/wait on something
such as select or a reading an event from a blocking socket.
Or just issue a generic process_events op and spin
ests and a read for write requests, and make things
DS> specific.
but then you still need the main line of code to block/wait on something
such as select or a reading an event from a blocking socket. sometimes a
specific wait will simplify things if you only have one pending
event. sure, for
sking was more in terms of
what could happen to Parrot while your write is in an unknown state.
Specifically, I'm concerned that I might want to say:
become immune to any events
perform write
re-sensitize to events
Well do you? Really? Because if the write blocks you
At 11:03 AM -0400 5/4/04, Uri Guttman wrote:
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> However...
DS> There are those pesky repeating events, and events from outside
DS> sources. Signals, mouse clicks, window resizes, repeating tim
of
what could happen to Parrot while your write is in an unknown state.
Specifically, I'm concerned that I might want to say:
become immune to any events
perform write
re-sensitize to events
But, if writes are implemented using the event-handling system, won't
th
sync IO brings)
i like that. just like RT-11 had (READ, READW and READC :)
DS> However...
DS> There are those pesky repeating events, and events from outside
DS> sources. Signals, mouse clicks, window resizes, repeating timer
DS> firings... stuff like that. Can anyone think of a r
At 4:17 PM +0200 5/4/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... stuff like that. Can anyone think of a reason that someone
would want to wait *specifically* on one type of event like this,
Well, just for symmetry
new Px, EventWait
set Px, 0.1
waitfor Px
But th
At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
On Tue, 2004-05-04 at 09:25, Dan Sugalski wrote:
Okay, I'm working up the design for the event and IO system so we can
get that underway (who, me, avoid the unpleasantness of strings?
Nah... :) and I've come across an interesting question.
The way
On Tue, 2004-05-04 at 09:25, Dan Sugalski wrote:
> Okay, I'm working up the design for the event and IO system so we can
> get that underway (who, me, avoid the unpleasantness of strings?
> Nah... :) and I've come across an interesting question.
>
> The way things are going to work with specific
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... stuff like that. Can anyone think of a reason that someone
> would want to wait *specifically* on one type of event like this,
Well, just for symmetry
new Px, EventWait
set Px, 0.1
waitfor Px
But that's normally (and now) done like:
sle
ches that async IO brings)
However...
There are those pesky repeating events, and events from outside
sources. Signals, mouse clicks, window resizes, repeating timer
firings... stuff like that. Can anyone think of a reason that someone
would want to wait *specifically* on one type of event like t
, which does:
- unblock SIGINT
- select in a while loop
- if select returns -1, check for EINTR and the sig_atomic_t flag
set by the signal handler
All this stuff needs to get out of events.c at some point, and we
probably better do it now rather than later. Not because they're not
events
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> All this stuff needs to get out of events.c at some point, and we
> probably better do it now rather than later.
Yeah. Thought about that too. I'm a bit unhappy with the current
config/gen/platform/* files.
Me thinks that we should do:
- s/generic/posix/
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ and another f'up myself ]
> The IO thread can then generate a SIGINT_EVENT and pthread_signal the
> event thread. And it could wait on various file-handles and on an
> internal pipe, which can be used to communicate file-handles to be
> waited on to th
tton I realized, that there is another option and
- of course - we'll have to handle IO events too.
So my local src/events.c does:
1) block all signals before any thread creation
2) install an event handler for SIGINT
3) start the event handler thread
4) start an IO handler thread, which does:
option and
- of course - we'll have to handle IO events too.
So my local src/events.c does:
1) block all signals before any thread creation
2) install an event handler for SIGINT
3) start the event handler thread
4) start an IO handler thread, which does:
- unblock SIGINT
- select in a whil
The Plan(tm) AFAIK is to convert signals to events[1]. Pressing ^C on the
console or such should be available to user defined exception or signal
handlers.
So the flow of information would be:
1) signal async per definition - in some thread
2) event-handler thread
Jeff Clites <[EMAIL PROTECTED]> wrote:
> But if the "event dispatch" thread is setting some flag for the target
> thread to detect, it's going to need to lock (or something similar) to
> make sure that the value of this flag is visible to other threads.
Yep, that's true. The event thread puts an
On Jan 17, 2004, at 12:33 PM, Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Ops that can leave the code segment have to explicitely check for
events.
But if the "event dispatch" thread is setti
bytecode (or segment). So it's slower
> to deliver events in large programs. That seems like a bad omen.
It depends, how bad it really is:
- it should be possible, to patch only the current subroutine, which
might or might not help (a Sub can still be huge). The program flow
can't
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
>> Ops that can leave the code segment have to explicitely check for=20
>> events.
> Then no need to patch invoke*.
Yep, that's true. I'm waiting for
n
amount of code twice.
It just seems bad that the efficiency of event delivery would be
proportional to the size of the bytecode (or segment). So it's slower
to deliver events in large programs. That seems like a bad omen.
... Also, once the handler is entered we'd
have to fix all of pat
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
What if control leaves the current code segment before you finish
patching it?
Ops that can leave the code segment have to explicitely check for
events.
Then no need to patch
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> What if control leaves the current code segment before you finish=20
> patching it? If an event is being delivered from another thread, this is=20=
Ops, that can leave the code segment have to explicitely check for
events.
> Gordon Henriksen
leo
On Saturday, January 17, 2004, at 05:51 , Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
... Also, once the handler is entered we'd have to fix all of patched
locations, which again could be time-consuming for large bytecode.
Please remember: only the current code segment has to b
On Saturday, January 17, 2004, at 05:53 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Other threads than the target could be executing the same chunk of
JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are conver
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Other threads than the target could be executing the same chunk
> of JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are converted to absolute memory locations.
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Where in the stream would we patch? If not in a loop, you may never hit
> the single patched location again, but still might not end for a very
> long time
Same as with prederefed run cores: backward branches, invoke*
> If we are patching all location
On Jan 16, 2004, at 1:20 PM, Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
2) Patch the native opcodes at these places with e.g. int3
I don't think that bytecode-modifying versions should fly; they're not
threadsafe,
Why? The bytecode is patched by a d
Leopold Toetsch wrote:
> Why? The bytecode is patched by a different thread *if* an
> event is due (which in CPU cycles is rare). And I don't see a
> thread safety problem. The (possibly different) CPU reads an
> opcode and runs it. Somewhere in the meantime, the opcode at
> that memory positi
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> 2) Patch the native opcodes at these places with e.g. int3
> I don't think that bytecode-modifying versions should fly; they're not
> threadsafe,
Why? The bytecode is patched by a different thread *if* an event is due
(which
k
every pace, if there is a cookie, it would be a big slowdown.
To minimze the overhead, the event thread throws a big piece of
wood in front of the fast running interpreter #5, which finally, after a
bit stumbling, realizes: "Oh, my cookie has arrived".
> This is probably a dumb que
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
>>Event handling currently works for all run cores[1] except JIT.
> What I'd planned for with events is a bit less responsive than the
> system you've put together for the
I'd hope that the event handler for a signal event could
elect to throw an exception; it could even be the default.
But the exception has to get into the thread somehow--
exceptions don't autonomously happen, and they require
considerable cooperation from the thread on which the
exception oc
gnals have nothing
to do with the program itself but come entire from the
outside. (Whereas with the regular events, the data
comes from outside but the choice to listen for the
data was made inside the program.)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--
m
to avert that attack vector.
> 1) explicitely insert checks, if events are to be handled
> 1a) everywhere or
> 1b) in places like described below under [1] c)
I like this (1b). With the JIT, an event check could be inlined to 1
load and 1 conditional branch to the event dispatcher, yes
At 1:45 PM -0500 1/16/04, Michal Wallace wrote:
On Fri, 16 Jan 2004, Dan Sugalski wrote:
2) Those that explicitly check for events
...
Ops like spin_in_event_loop (or whatever we call it) or checkevent is
in category two. They check events because, well, that's what they're
supp
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> 2) Those that explicitly check for events
...
> Ops like spin_in_event_loop (or whatever we call it) or checkevent is
> in category two. They check events because, well, that's what they're
> supposed to do. Compilers shoul
At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
Event handling currently works for all run cores[1] except JIT.
The JIT core can't use the schemes described below, but we could:
1) explicitely insert checks, if events are to be handled
1a) everywhere or
1b) in places like described below
Event handling currently works for all run cores[1] except JIT.
The JIT core can't use the schemes described below, but we could:
1) explicitely insert checks, if events are to be handled
1a) everywhere or
1b) in places like described below under [1] c)
2) Patch the native opcodes at these p
ewing this aging thread...)
Not to throw a damper on the events party or anything, but an
event-based system with asynchronous I/O isn't capable of saturating an
SMP box's processors. This is one of the major reasons for using threads
in web servers. It's also a significant reas
reads.
other than the fork issue on win32, it can be done with events.
Therein lies the rub. There's a lot of win32 out there, and it needs to
be supported. Will parrot have a pseudo fork system (that actually
works) for platforms with no native fork?
IMO, parrot should be able to support bot
>>>>> "KS" == K Stol <[EMAIL PROTECTED]> writes:
KS> Is it true that there will be operations for generating an event?
KS> So, unlike interrupt signals, these events are generated 'inside'
KS> the system. So, will there be an op like "
Hello,
I've got a question concerning events.
As I read from previous discussions, an event is a message to the Parrot Interpreter
saying something has happened: I/O jobs were finished, a timer went off, etc. These
things are from 'outside' the system, that is something outside
On Tue, Jul 22, 2003 at 11:41:25PM -0400, Dan Sugalski wrote:
> First, to get it out of the way, I don't have to convince you of
> anything. You have to convince me. For better or worse I'm
> responsible for the design and its ultimately my decision. If you
> don't want async IO, it's time to ma
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> We are going to do all I/O under the hood asynchronously.
> Completed async IO puts an event in the event queue...
I am new to parrot, but I've had plenty of experience with (non-unix)
I/O systems. Having a totally async core in Parrot is pretty clea
Dan Sugalski wrote:
[snip]
> Here's what we *are* doing.
>
> We are going to do all I/O under the hood asynchronously. Completed
> async IO puts an event in the event queue.
>
> We are going to have a single unified event queue. All IO, timer,
> signal, and UI event
been said, there are some things we *aren't* doing.
We're not executing parrot bytecode code at interrupt time. Interrupt
handlers put events into parrot's event queue for processing later.
We're *not* forcing anyone to use async IO. I fully expect that 99%
of the code emitted by
On Tue, Jul 22, 2003 at 10:05:49AM -0700 it came to pass that Damien Neil wrote:
> Some Java programs, as you say, build a
> single-threaded, non-blocking, event-dispatched IO mechanism on top
> of this. Java does not, however, have any support for interrupts;
> it is not possible to do AIO in Jav
On Tue, Jul 22, 2003 at 01:10:24PM +0200, Jos Visser wrote:
> Lots of Java programs simulate AIO by using threads. Almost all Java IO
> mechanisms are blocking and this means that doing interesting work while
> the IO is in progress requires some mechanism that involves a separate
> thread with a c
On Mon, Jul 21, 2003 at 06:29:36PM -0700 it came to pass that Damien Neil wrote:
>
> Do you know of a program that does this (simulated AIO via threads)?
> (Again, I'm not disputing your claim--it's just that this is
> completely contrary to my experience, and I'd like to know more
> about it.)
>
On Sun, Jul 20, 2003 at 11:59:00AM -0400, Dan Sugalski wrote:
> We're supporting interrupts at the interpreter level because we must.
> It doesn't matter much whether we like them, or we think they're a
> good idea, the languages we target require them to be there. Perl 5,
> Perl 6, Python, and
At 1:09 PM -0400 7/20/03, Michal Wallace wrote:
On Sun, 20 Jul 2003, Dan Sugalski wrote:
>It would be entirely possible for Parrot (or a Parrot library) to
>use AIO at a low level, without introducing interrupts to the VM layer.
Sure. But what'd be the point? Adding in interrupts allows a numb
you want to.
Hey Dan,
I'm just curious... When you say IO callbacks, does that
mean external C code calling back into the parrot VM?
I wrote a python interface to the win32 MIDI routines a
while back. At first I just called the DLL and that worked
fine for output, but if I tried to read
-done event system) can't use AIO at a low level to support
async file IO on Unix.
Yep, definitely. This is why there's the unified event system, so you
can do async I/O on files, on sockets, handle window system events,
interprocess messages and interthread messages with a single point o
On Fri, Jul 18, 2003 at 05:58:41PM -0400, Uri Guttman wrote:
> and event loop i/o doesn't usually support async file i/o. many people
> conflate the two. event i/o handles sockets, pipes and such but none
> support files. the issue is that the async file i/o api is so different
> (or non-existant)
e popular, simply
> because of parrot's availability.
I'd be interested in seeing specific examples of problems that will
be solved by adding AIO support to the VM layer. How will this feature
be used in real-world programs?
> > Outside of signals and AIO, what requires async ev
On Fri, Jul 18, 2003 at 01:06:03PM -0700, Damien Neil wrote:
> Also, given that asynchronous IO is a fairly unpopular programming
> technique these days (non-blocking event-loop IO and blocking
> threaded IO are far more common), I would think long and hard before
> placing support for it as a core
> "BG" == Benjamin Goldberg <[EMAIL PROTECTED]> writes:
BG> Damien Neil wrote:
BG> [snip]
>> Also, given that asynchronous IO is a fairly unpopular programming
>> technique these days (non-blocking event-loop IO and blocking
>> threaded IO are far more common), I would think long and
ion.
>
> Outside of signals and AIO, what requires async event dispatch?
> User events, as you pointed out above, are better handled through
> an explicit request for the next event.
Inter-thread notification and timers? True, these *could* be considered
to be "user events"
On Fri, Jul 18, 2003 at 11:29:27AM -0400, Dan Sugalski wrote:
> Nope, that won't work. A lot of what's done is really "main thread
> with interrupts" and that doesn't map well to doing all signal
> handling in separate threads. You really do want to pause the ma
At 6:01 PM +0200 7/18/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Events should be checked and processed in several instances:
3) When we do a quick check to see if there are pending events to
be processed
I have now a patch ready, which does 3) without add
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Events should be checked and processed in several instances:
> 3) When we do a quick check to see if there are pending events to be processed
I have now a patch ready, which does 3) without additioal performacne
penalty for all cores except J
programs come to
mind) The third is to be scattered in generated code to make sure
that events are occasionally checked for, and will probably drain
only high-priority events and at most a single low-priorty event.
While it's possibly politically impossible (many people are very
attached to
ird is to be scattered in generated code to make sure
> that events are occasionally checked for, and will probably drain
> only high-priority events and at most a single low-priorty event.
While it's possibly politically impossible (many people are very
attached to Unix signals),
1 - 100 of 109 matches
Mail list logo
