> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes:
JNP> On Wed, Jan 19, 2000 at 11:06:15PM -0500, [EMAIL PROTECTED] wrote:
>> well, i finally spent a little serious time and found my stupid bug. bad
>> hash name in a constructor method vs. its use in another method. it
>> passed
On Wed, Jan 19, 2000 at 10:33:03PM -0500, [EMAIL PROTECTED] wrote:
> > "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes:
>
> >> #5 0x5b328 in Perl_sighandler ()
> >> #6 Yikes!
>
> JNP> Hm, an event handler died and the recovery was interrupted by a signal.
On Wed, Jan 19, 2000 at 11:06:15PM -0500, [EMAIL PROTECTED] wrote:
> well, i finally spent a little serious time and found my stupid bug. bad
> hash name in a constructor method vs. its use in another method. it
> passed undef as a socket/fd to Event::io->new. even though that was my
> bug, it sho
well, i finally spent a little serious time and found my stupid bug. bad
hash name in a constructor method vs. its use in another method. it
passed undef as a socket/fd to Event::io->new. even though that was my
bug, it should have caused a clean exit/die from event.pm so i feel this
is a bug.
a
> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes:
>> #5 0x5b328 in Perl_sighandler ()
>> #6 Yikes!
JNP> Hm, an event handler died and the recovery was interrupted by a signal.
i canceled the write event but i never made any signal handler. maybe a
sigpip
On Wed, Jan 19, 2000 at 04:00:03PM -0500, Joshua N Pritikin wrote:
> That's a cool test script. It certainly appears to be failing to cancel
> watchers and refusing to exit. I need to dust off my thinking cap... :-)
I think I found the problem. Try the attached patch over 0.58. This
patches
On Wed, Jan 19, 2000 at 09:18:56PM +0100, [EMAIL PROTECTED] wrote:
> Just to become familiar with the debug feature before I use it in the real code I
>wrote a simple
> test
> script. I recognized the following: if I use unloop() to stop the loop, the watcher
>counter does
> not
> change. If I u
Just to become familiar with the debug feature before I use it in the real code I
wrote a simple
test
script. I recognized the following: if I use unloop() to stop the loop, the watcher
counter does
not
change. If I use the cancel phrase (as I send it with this message), there is a point
when a
> Huh? _memory_counters() returns an array. You can formatted it as well
> or badly as you like. :-)
O, hm! Indeed ... sorry! I built it so quickly into a warn() statement that I missed
that format point ...
> This little event feature is just a stop gap.
Ok.
Jochen
On Wed, Jan 19, 2000 at 07:32:48PM +0100, [EMAIL PROTECTED] wrote:
> > Perhaps you can do something like this:
> >
> > Event->timer(interval => 2, cb => sub {
> > warn 'Event memory: ' . join ' ', Event::_memory_counters()
> > });
>
> I see. I took my first steps and recognized the format
On Wed, Jan 19, 2000 at 06:30:04PM +, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin <[EMAIL PROTECTED]> wrote
> > On Wed, Jan 19, 2000 at 12:19:34AM -0500, [EMAIL PROTECTED] wrote:
> > > i am wondering what signal is being handled there as well. sigpipe?
> >
> > You are aware that signal handl
> Perhaps you can do something like this:
>
> Event->timer(interval => 2, cb => sub {
> warn 'Event memory: ' . join ' ', Event::_memory_counters()
> });
I see. I took my first steps and recognized the format:
2000
So, there are two watchers of type 4. Unfortunately, I'm
Joshua N Pritikin <[EMAIL PROTECTED]> wrote
> On Wed, Jan 19, 2000 at 12:19:34AM -0500, [EMAIL PROTECTED] wrote:
> > i am wondering what signal is being handled there as well. sigpipe?
>
> You are aware that signal handlers are not safe?
I assume you mean Perl signal handlers. I'd always assum
On Wed, Jan 19, 2000 at 07:09:02PM +0100, [EMAIL PROTECTED] wrote:
> So, I saw the patch included the free() checking code as well, so I will now start
>to instruct my
> application to run with Events debugging feature. I will report the results.
>
> _memory_counters() replies the number of watc
Hello,
> I'll use a different #define ...
> EVENT_MEMORY_DEBUG. Attached is a patch vs. 0.58. Can you add
> -DEVENT_MEMORY_DEBUG to the Makefile and try again?
Well, this works! I applied your patch, and the new Event.pm (build with
-DEVENT_MEMORY_DEBUG)
passed all tests successfully even wit
On Wed, Jan 19, 2000 at 05:25:35PM +0100, [EMAIL PROTECTED] wrote:
> O, hm, by the way, I see this is a threaded perl (which you do not suggest) ... but
>can this
> really cause such problem? I'll see if I found another installation without
>threading ...
As long as you don't use threads, it sh
On Wed, Jan 19, 2000 at 05:33:20PM +0100, [EMAIL PROTECTED] wrote:
> > > "Reference miscount in sv_replace() at blib/lib/Event.pm line 184."
> >
> > Whoa! I've never seen that. Can you post the output from 'perl -V'?
> > Maybe I can try to reproduce the problem with exactly the same version
> >
On Sun, Jan 16, 2000 at 03:37:16PM +, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin <[EMAIL PROTECTED]> writes:
> >Furthermore, Event tries
> >to ignore the implications of multiple threads as much as possible.
>
> Which is a weakness. Modern Tcl/Tk can at least "tolerate" multiple threads.
On 19 Jan, [EMAIL PROTECTED] wrote:
> perl -V reported that my perl was not compiled for debugging, so I set DEBUGGING in
> Makefile.PL by adding "DEFINE => '-DDEBUGGING'". Sorry, I'm not that familiar with
> MakeMaker, but a look through the docs and a check of the resulting makefile made me
> th
> > This means I have to recompile Event with that switch, am I right?
>
> It depends. Check 'perl -V' to see if it is already defined.
perl -V reported that my perl was not compiled for debugging, so I set DEBUGGING in
Makefile.PL by adding "DEFINE => '-DDEBUGGING'". Sorry, I'm not that familia
On Wed, Jan 19, 2000 at 04:25:05PM +0100, [EMAIL PROTECTED] wrote:
> > #if DEBUGGING
>
> This means I have to recompile Event with that switch, am I right?
It depends. Check 'perl -V' to see if it is already defined.
> > As you can see, this is very simplistic since it doesn't keep track of
>
On Thu, Jan 13, 2000 at 05:48:30PM -0500, [EMAIL PROTECTED] wrote:
> JNP> Oh right. Gee, that isn't documented yet. (Oops :-) Try this:
>
> we have to work on the docs for event. seriously! i have too much on my
> plate right now but it has to get done if we are serious about one event
> loo
On Wed, Jan 19, 2000 at 12:19:34AM -0500, [EMAIL PROTECTED] wrote:
> well, i said i would hammer event.pm and i just got a core dump. here is
> the stack trace from gdb:
>
> (gdb) bt
> #0 0xff216870 in _kill ()
> #1 0x99ac4 in Perl_apply ()
> #2 0x92e20 in Perl_pp_kill ()
> #3 0x9ef6c in Perl
On Wed, Jan 19, 2000 at 11:21:31AM +0100, [EMAIL PROTECTED] wrote:
> I'm still working on a distributed client/server system on the base of
> Event. My test server grows and grows if stressed by a lot of client
> connections (and at a certain point this starts to cause errors). This
> growth has b
Hello,
I'm still working on a distributed client/server system on the base of
Event. My test server grows and grows if stressed by a lot of client
connections (and at a certain point this starts to cause errors). This
growth has been significantly reduced (at least in the amount of
RESERVED memor
25 matches
Mail list logo
