> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> This is the Perl interpreter:
SC> while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
SC> PERL_ASYNC_CHECK();
SC> }
SC> The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
SC> do anything.
> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
RC> With a tightly integrated event loop, blocking perl level I/O can be
RC> implemented in terms of internal asynchronous I/O. An interpreter can
RC> then block while perl is free to do other things, like say run other
RC> interpret
On Fri, Jan 05, 2001 at 07:39:36PM -0500, Uri Guttman wrote:
> the former means the ENTIRE guts of perl would be run on the event
> loop. this is a cool idea IMO. the perl interpreter IS an event loop.
>
> so tell me, is that nuts or what? :)
No, it's exactly what Perl 5 does.
This is the Perl
> "n" == <[EMAIL PROTECTED]> writes:
n> I have some sympathy with Uri's position here. Signals and event
n> loops are close cousins. What I am less clear about is whether we
n> want to go down the Tcl route, or do something even more radical
n> like making op despatch and the event
On Wed, Dec 27, 2000 at 01:00:14PM -0500, Dan Sugalski wrote:
> At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
> >--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Why? For variables, math is math--2+2=4 regardless of
> > > whether you're one or
> > > two's complement, or BCD-encoded, or use t
> "n" == <[EMAIL PROTECTED]> writes:
>> I'm less worried about long running ops (whose fix is just a SMOP, after
>> all... :) than I am blocked ops. We can be as clever as we want with event
>> dispatch and async handling but it won't do us a darned bit of good if the
>> interpre
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> do you mean event_flag is set to the actual op to handle the event? cute
>> use of a value based flag.
DS> The problem there is that it gets in the way if multiple events
DS> are pending, unless there's exactly one possible routin
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>do you mean event_flag is set to the actual op to handle the event? cute
>>use of a value based flag.
>
>The problem there is that it gets in the way if multiple events are
>pending, unless there's exactly one possible routine we can call, in which
>cas
> "n" == nick <[EMAIL PROTECTED]> writes:
n> It is my personal style to use non-NULL value as "flag" - it dates
n> back to "my" RTOS on TI's 16-bit micros where memory was precious -
n> having a flag and a value was wasteful.
in my rt-11 assembly and heavy c days i did it too. i pro
Uri Guttman <[EMAIL PROTECTED]> writes:
>
> n>push(op_ptr);
>
>fake recursion. :) this is simpler, saving the old op to a stack. you
>need to also deal with popping that back when the handler is done.
Again using hardware as a model I would like an event "context switch"
to look like a "cal
At 03:57 PM 1/5/01 -0500, Uri Guttman wrote:
> > "n" == nick <[EMAIL PROTECTED]> writes:
> n>op_ptr = event_flag; // it _is_ the ops we want to do
> n>event_flag = NULL;
>
>do you mean event_flag is set to the actual op to handle the event? cute
>use of a value based flag.
The pr
> "n" == nick <[EMAIL PROTECTED]> writes:
>> that is so we don't dispatch events between every op code.
n> Why not? - hardware does.
n> Also once event is posted we keep going into the decrement loop
n> for all the ops until we decide to do it.
n> I don't think despatching ever
Uri Guttman <[EMAIL PROTECTED]> writes:
> n> Explain your counter idea some more (I will _read_ rather than skim
> n> the RFCs one of these days...)
>
> n> It seems to me that decrementing counter is extra inner-loop cost,
> n> and you still have the conditional branch delay when you test
> n
At 08:18 PM 1/5/01 +, John van V wrote:
>I am supporting regular GNU licensing to relieve the pain I am hearing
>about in the commercial zone where folks are allegedly up to NG.
People who are going to steal the source will do so regardless of the
license on the source, and the people who
I am supporting regular GNU licensing to relieve the pain I am hearing about in the
commercial zone where folks are allegedly up to NG.
Also if we use the GNU license, then we dont have to worry about applications meant
for perl being written in some other less appropriate
language because of
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> It works pretty well, all things considered. Not the easiest way to
DS> program, but async code's always a big pain in the neck.
ahh, back to the days of rt-11 which had optional callbacks for all of
its i/o calls including files. n
> At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > > step away from saying to hell with it all and going fully public domain.
> > > (Or at least pushing for it, as I do
> "n" == nick <[EMAIL PROTECTED]> writes:
>> a single test flag which is set by a
>> variety of events is all that is needed. but we also should have an op
>> loop with no test as the code could use an event loop to handle all
>> events. then dispatching is not done inline. would it
At 07:11 PM 1/5/01 +, [EMAIL PROTECTED] wrote:
>Nicholas Clark <[EMAIL PROTECTED]> writes:
> >> and maybe have the return data have some 'I/O complete' marker so
> async I/O
> >> will work out properly.
>
>Anyone that has experience in writing prefetch style code please weigh in
>with the pit
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> 1. What are the consequences for t
At 01:19 PM 1/5/01 -0500, Uri Guttman wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> >> and where is the event test call made?
>
> NI> It isn't. PL_next_op is set by C signal handler.
>
>and that has to be memory and data structure safe.
>
> NI> In practice I suspect
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>we are in violent agreement.
I think so too ;-)
>a single test flag which is set by a
>variety of events is all that is needed. but we also should have an op
>loop with no test as the code could use an event loop to handle all
>events. then dispatching
Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>tell can be seek F, 0, SEEK_CUR
I initally had stdio like split seek/tell. I actually implemented
the merged form as you suggest - but it turned out to be a mistake
so they are currently separate again.
The reason it is a mistake is one wants seek(F
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I've been pretty much assuming we'd need:
DS>open
DS>close
DS>seek
DS>tell
DS>push_filter
DS>pop_filter
DS>read
DS>unread
DS>write
DS>prefetch
DS> and maybe have the return
> "FB" == Filipe Brandenburger <[EMAIL PROTECTED]> writes:
FB> What about pread and pwrite, for reading and writing to seekable files
FB> in multiple threads? pread and pwrite get as a parameter a offset that
FB> they use to seek the file before reading or writing, but doing it
>On Fri, Jan 05, 2001 at 12:37:39PM -0500, Dan Sugalski wrote:
>> I've been pretty much assuming we'd need:
>>
>>open
>>close
>>seek
>>tell
>>push_filter
>>pop_filter
>>read
>>unread
>>write
>>prefetch
>>
What abo
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>> and where is the event test call made?
NI> It isn't. PL_next_op is set by C signal handler.
and that has to be memory and data structure safe.
NI> In practice I suspect we need the test :
NI> while (PL_op = (PL_sig_op) ? P
On Fri, Jan 05, 2001 at 12:37:39PM -0500, Dan Sugalski wrote:
> I've been pretty much assuming we'd need:
>
>open
>close
>seek
>tell
tell can be seek F, 0, SEEK_CUR
(unless tell is intended to return some other information on unseekable
files. In which case internally one could
At 09:22 PM 1/4/01 +, [EMAIL PROTECTED] wrote:
>Simon Cozens <[EMAIL PROTECTED]> writes:
> >On Wed, Jan 03, 2001 at 11:03:08PM +, Nick Ing-Simmons wrote:
> >> I am willing to cast bleadperl5's PerlIO into the form of a _draft_ PDD
> >> for perl6 - i.e. "this is what it does now", not "this
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> Screw Visual Basic, Perl should be the scripting language of
> choice for, well, everything! :)
Well... then someone needs to make it easier to dynamically access the Win32
API from Perl.
Visual Basic has been growing up too. And it's a whole l
At 09:11 AM 1/5/01 -0600, Jarkko Hietaniemi wrote:
>On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote:
> > On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> >
> > > I personally think that the relying on LGPL'ed code is completely
> > > reasonable. Some will disagree, so we need to come t
At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > step away from saying to hell with it all and going fully public domain.
> > (Or at least pushing for it, as I don't control
On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote:
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
>
> There are ac
On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> I personally think that the relying on LGPL'ed code is completely
> reasonable. Some will disagree, so we need to come to a consensus on this
> as a community.
There are actually a couple of different mostly-independent issues, but
yes, we'll need to
On Fri, Jan 05, 2001 at 12:38:54PM +, Nicholas Clark wrote:
> On Tue, Jan 02, 2001 at 12:00:19PM -0500, Dan Sugalski wrote:
> > I'm going to try really hard to avoid that particular pitfall, if for no
> > other reason than you can set things on the VMS C compilers such that you
> > have 64-b
On Tue, Jan 02, 2001 at 12:00:19PM -0500, Dan Sugalski wrote:
> I'm going to try really hard to avoid that particular pitfall, if for no
> other reason than you can set things on the VMS C compilers such that you
> have 64-bit pointers and 32-bit ints by default. (Takes some work, but it's
> do
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>but the question remains, what code triggers a signal handler? would you
>put a test in the very tight loop of the the op dispatcher?
Not a test. The C level signal handler just fossicks with the variables
that very tight loop is using.
>
> n> But i
37 matches
Mail list logo
