perl 5.005_03 core dumps -- singal interrupt related

[p5pRT]

Migrated from rt.perl.org#1955 (status was 'resolved')

Searchable as RT1955$

[p5pRT]

From [Unknown Contact. See original ticket]

At 09​:54 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

The fancy stuff with Sigslot avoids any chance of loosing signals during inspection of the signal counters. The signal counters are polled every iteration through the event loop. This works well for easy stuff\, meaning\, your code is Event driven and doesn't care about signal latency. My hope was that run-time opcode substitution would give us more ways to cope with these nasties. Where does that patch stand?

In the works\, pending a delivery of tuits. :)

I usually give up at this point because I can see that signals are a mess and getting them to work with multiple threads is going to make it worse. I am encouraged to hear that linux does not follow POSIX. My experience with POSIX threads has not been very encouraging.

I wouldn't get too encouraged. Linux threads are an attempt to shoehorn POSIX threads onto a system that actively disapproves of them. The big issues are signals and process table exhaustion\, but there are other niggly things. (Each thread has a separate pid\, for example\, and the kernel doesn't really know what 'process' a thread belongs to)

My unsubstantiated suspicion is that the POSIX thread spec was written well ahead of any working implementation. I think it is likely that the linux model is better even though I haven't checked myself. This is just a vague feeling. I might be completely backwards here.

In some ways its worse. Because threads are really separate processes\, only the thread that actually gets the signal delivered can see it. Not necessarily a bad thing (though it makes separate signal-handling threads trickier) but it is in direct contradiction to the standard they're implementing. (And for all its limits\, POSIX threads were designed by a bunch of experienced\, clever guys who got a standard that managed to meet the requirements of the folks involved. I'm not sure that the Linux changes have that level of experience behind their changes)

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

At 09​:24 PM 1/11/00 -0500\, Ilya Zakharevich wrote​:

But since safe signals are not possible (see XSUBs)\, and require a significant rewrite of the most important "do a lot" Perl opcodes (at any checkpoint we should be ready for a longjump)\, this is still rather moot.

Safe immediate signal handlers in perl aren't possible. Safe deferred signal handlers in perl certainly are. A difference I know you're aware of\, but we're all using shorthand notation and I don't think everyone's shorthand is the same...

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

At 09​:28 PM 1/11/00 -0500\, Ilya Zakharevich wrote​:

On Tue\, Jan 11\, 2000 at 05​:22​:20PM -0500\, Dan Sugalski wrote​:

Why do you thing it is not going to be waiting on a blocking system call most of the time? For many threading paradigms this is exactly what happens.

So we have sync system calls instead spawn off a thread to do the call while the spawning thread cond_waits on something. To wake the thread you kill the thread doing the syscall and pop a cond_signal to the waiting thread. There are other ways\, too\, of course.

You still think that you can wake something which cond_wait()s from another thread. And you make things extremely complicated and extremely unefficient.

Yes I do\, and no it isn't. Perl code does a cond_wait. The cond_wait code stores the condition in the thread structure and waits. Something needs to wake the thread\, so it sets the condition and wakes it. No Big Deal.

And yes\, a new thread for long syscalls is inefficient. (And a completely different topic than cond_waits) Thread pools make it cheaper (or at least amortize the costs) and if the call is likely to block for a while anyway the real expense is essentially non-existant.

What made you thingk cond_wait() is not a blocking system call?

What makes you think the cond_wait that I'm thinking of is the one you're thinking of? And what makes you think I'm not considering tracking the condition and signalling it?

Waking *all* the thread which wait on this?

Yeah\, and....? The underlying code for the other threads (assuming that other threads are even waiting on the same thing) see the condition wasn't for them and re-wait. Spurious wakeups are a part of life\, aren't that common\, and handling them is cheap.

Yes\, it does mean a bit of extra code in the core\, but it's not code that's in any sort of critical performance path.

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 10​:18​:24AM -0500\, dan@​sidhe.org wrote​:

At 09​:54 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

I usually give up at this point because I can see that signals are a mess and getting them to work with multiple threads is going to make it worse. I am encouraged to hear that linux does not follow POSIX. My experience with POSIX threads has not been very encouraging.

I wouldn't get too encouraged. Linux threads are an attempt to shoehorn POSIX threads onto a system that actively disapproves of them. The big issues are signals and process table exhaustion\, but there are other niggly things. (Each thread has a separate pid\, for example\, and the kernel doesn't really know what 'process' a thread belongs to)

So what? I know (from kernel traffic) they are aware of and fixing the process table exhaustion...

My unsubstantiated suspicion is that the POSIX thread spec was written well ahead of any working implementation. I think it is likely that the linux model is better even though I haven't checked myself. This is just a vague feeling. I might be completely backwards here.

In some ways its worse. Because threads are really separate processes\,

What's the difference? Memory sharing is the same\, right?

only the thread that actually gets the signal delivered can see it.

Yes. That's one of the reasons I felt that linux might be an improvement over the POSIX mess.

Not necessarily a bad thing (though it makes separate signal-handling threads trickier)

I never understood the alure of routing all the signals to a single signal-handling thread. Can anyone comment on this?

but it is in direct contradiction to the standard they're implementing.

True.

(And for all its limits\, POSIX threads were designed by a bunch of experienced\, clever guys who got a standard that managed to meet the requirements of the folks involved. I'm not sure that the Linux changes have that level of experience behind their changes)

As seen from here\, that doesn't sound conclusive one way or the other.

-- "Never ascribe to malice that which can be explained by stupidity."   via\, but not speaking for Deutsche Bank

[p5pRT]

From [Unknown Contact. See original ticket]

At 10​:35 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

On Wed\, Jan 12\, 2000 at 10​:18​:24AM -0500\, dan@​sidhe.org wrote​:

At 09​:54 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

I usually give up at this point because I can see that signals are a mess and getting them to work with multiple threads is going to make it worse. I am encouraged to hear that linux does not follow POSIX. My experience with POSIX threads has not been very encouraging.

I wouldn't get too encouraged. Linux threads are an attempt to shoehorn POSIX threads onto a system that actively disapproves of them. The big issues are signals and process table exhaustion\, but there are other niggly things. (Each thread has a separate pid\, for example\, and the kernel doesn't really know what 'process' a thread belongs to)

So what? I know (from kernel traffic) they are aware of and fixing the process table exhaustion...

Good. I hadn't seen that\, but I only skim the weekly summaries occasionally.

My unsubstantiated suspicion is that the POSIX thread spec was written well ahead of any working implementation. I think it is likely that the linux model is better even though I haven't checked myself. This is just a vague feeling. I might be completely backwards here.

In some ways its worse. Because threads are really separate processes\,

What's the difference? Memory sharing is the same\, right?

Yes\, though there's more to a thread than memory sharing. (You can currently flock yourself into a deadlock too\, FWIW\, though hopefully they're fixing that\, too)

only the thread that actually gets the signal delivered can see it.

Yes. That's one of the reasons I felt that linux might be an improvement over the POSIX mess.

In some ways it is\, for the synchronous signals--they're more installed error handlers than anything else. Async signals\, on the other hand\, are events rather than errors\, and are delivered to the *process*\, not to the thread. Who should get SIGHUP\, or SIGCHLD\, or SIGCONT\, or SIGIO? These all deal with process-level events\, and the thread that was responsible for them being generated (if you can even figure that out easily) isn't necessarily going to be the one that should handle them.

Not necessarily a bad thing (though it makes separate signal-handling threads trickier)

I never understood the alure of routing all the signals to a single signal-handling thread. Can anyone comment on this?

It makes handling the event signals easier. You just route 'em all to a single thread that deals with them\, rather than having to cope with them in all your threads.

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From @TimToady

Fisher Mark writes​: : (Hmmm. I wonder what would be the performance of a text editor written in : Perl?)

Depends on how you implement your character insertion\, your screen refresh\, and your various incestuous internal hooks. But mostly it depends on whether you call it pim or pemacs. :-)

Larry

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 10​:56​:06AM -0500\, dan@​sidhe.org wrote​:

At 10​:35 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

On Wed\, Jan 12\, 2000 at 10​:18​:24AM -0500\, dan@​sidhe.org wrote​:

In some ways its worse. Because threads are really separate processes\,

What's the difference? Memory sharing is the same\, right?

Yes\, though there's more to a thread than memory sharing. (You can currently flock yourself into a deadlock too\, FWIW\, though hopefully they're fixing that\, too)

Yah\, they're definitely aware of that.

only the thread that actually gets the signal delivered can see it.

Yes. That's one of the reasons I felt that linux might be an improvement over the POSIX mess.

In some ways it is\, for the synchronous signals--they're more installed error handlers than anything else. Async signals\, on the other hand\, are events rather than errors\, and are delivered to the *process*\, not to the thread. Who should get SIGHUP\, or SIGCHLD\, or SIGCONT\, or SIGIO? These all deal with process-level events\, and the thread that was responsible for them being generated (if you can even figure that out easily) isn't necessarily going to be the one that should handle them.

I don't know. At least the control is in the hands of the developer. On the other hand\, perhaps POSIX provides this as an option too. I am hardly qualified to debate this stuff.

I never understood the alure of routing all the signals to a single signal-handling thread. Can anyone comment on this?

It makes handling the event signals easier. You just route 'em all to a single thread that deals with them\, rather than having to cope with them in all your threads.

I'm still mystified. Obviously the library/kernel can do this automatically but what is so hard about doing it at the application level? Wouldn't it just be a matter of adding a bunch of handlers to the children threads​:

  static Signal_t process_sighandler(int sig) { kill(ParentPID\, sig); }

Am I missing something?

-- "Never ascribe to malice that which can be explained by stupidity."   via\, but not speaking for Deutsche Bank

[p5pRT]

From [Unknown Contact. See original ticket]

At 11​:17 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

On Wed\, Jan 12\, 2000 at 10​:56​:06AM -0500\, dan@​sidhe.org wrote​:

At 10​:35 AM 1/12/00 -0500\, Joshua N Pritikin wrote​:

only the thread that actually gets the signal delivered can see it.

Yes. That's one of the reasons I felt that linux might be an improvement over the POSIX mess.

In some ways it is\, for the synchronous signals--they're more installed error handlers than anything else. Async signals\, on the other hand\, are events rather than errors\, and are delivered to the *process*\, not to the thread. Who should get SIGHUP\, or SIGCHLD\, or SIGCONT\, or SIGIO? These all deal with process-level events\, and the thread that was responsible for them being generated (if you can even figure that out easily) isn't necessarily going to be the one that should handle them.

I don't know. At least the control is in the hands of the developer. On the other hand\, perhaps POSIX provides this as an option too. I am hardly qualified to debate this stuff.

Well\, POSIX doesn't\, really. More to the point it explicitly makes the "what thread gets a signal" implementation-defined. So what Linux is doing is mostly OK\, except it's my understanding that signals are supposed to roll over--if they get popped to a thread that's blocked that particular signal then the signal isn't supposed to be lost\, instead sent to another thread.

I think part of this is to accommodate those systems that use a LWP/Kernel thread scheme--the signal goes to the process/KT and gets delivered to the first thread that runs on that process/KT that's set itself to handle the signal.

POSIX threads are a sort of cross-platform compromise. Not 100% great\, but workable on a wide range of OS/platform setups. Which does mean that Linux can do it better since it's a private implementation\, but the problem is they fib and say they're POSIX (and thus you'd expect them to behave in the POSIX manner) but they really aren't.

I never understood the alure of routing all the signals to a single signal-handling thread. Can anyone comment on this?

It makes handling the event signals easier. You just route 'em all to a single thread that deals with them\, rather than having to cope with them in all your threads.

I'm still mystified. Obviously the library/kernel can do this automatically but what is so hard about doing it at the application level? Wouldn't it just be a matter of adding a bunch of handlers to the children threads​:

static Signal_t process_sighandler(int sig) { kill(ParentPID\, sig); }

Am I missing something?

Nope. But that's error prone and\, more to the point\, platform-specific in a way it shouldn't be if it's really POSIX threads. (And I'm not sure that the parent pid's set right\, but you can always set the signal thread pid in a global somewhere and work with that)

Not that we can't (or shouldn't) deal with it at the perl level\, of course. Just an annoyance.

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

Larry Wall wrote​:

Fisher Mark writes​: : (Hmmm. I wonder what would be the performance of a text editor written in : Perl?)

Depends on how you implement your character insertion\, your screen refresh\, and your various incestuous internal hooks. But mostly it depends on whether you call it pim or pemacs. :-)

actually\, its called "gedi" and should be rolled into the Tk800.017 release. (if not\, I think its in the widget demo) most of it is perl subs that Nick and I scrunched into Tk​::Text and Tk​::TextUndo. It has all the functionality of the textedit program on unix.

ok\, ok\, a lot of the underlying code is C (character inserts\, and the like) but\, a lot of the higher level stuff is pure perl. (search and replace\, undo/redo\, etc) never benchmarked it though...

Greg

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 10​:20​:18AM -0500\, Dan Sugalski wrote​:

At 09​:24 PM 1/11/00 -0500\, Ilya Zakharevich wrote​:

But since safe signals are not possible (see XSUBs)\, and require a significant rewrite of the most important "do a lot" Perl opcodes (at any checkpoint we should be ready for a longjump)\, this is still rather moot.

Safe immediate signal handlers in perl aren't possible.

As I demonstrated\, they are for a large (though not enormous) subset of things people want to do in signal handlers.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 02​:49 PM 1/12/00 -0500\, Ilya Zakharevich wrote​:

On Wed\, Jan 12\, 2000 at 10​:20​:18AM -0500\, Dan Sugalski wrote​:

At 09​:24 PM 1/11/00 -0500\, Ilya Zakharevich wrote​:

But since safe signals are not possible (see XSUBs)\, and require a significant rewrite of the most important "do a lot" Perl opcodes (at any checkpoint we should be ready for a longjump)\, this is still rather moot.

Safe immediate signal handlers in perl aren't possible.

As I demonstrated\, they are for a large (though not enormous) subset of things people want to do in signal handlers.

s/want to do/think they're limited to doing/;

Coming from a platform with very strong asynchronous leanings (VMS)\, it's been my experience that people with a mainly Unix or Unix-inspired background just don't expect a whole lot from their async sub-system. Probably because signals are so terribly limited and the only other experiences they have are with X and\, well\, the less said the better... :)

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 10​:28​:40AM -0500\, Dan Sugalski wrote​:

You still think that you can wake something which cond_wait()s from another thread. And you make things extremely complicated and extremely unefficient.

Yes I do\, and no it isn't. Perl code does a cond_wait. The cond_wait code stores the condition in the thread structure and waits. Something needs to wake the thread\, so it sets the condition and wakes it. No Big Deal.

If it were correct\, sure. But it is not. This will not "wake it"\, it will wake all the threads which wait on this condition. So some more work is needed.

And yes\, a new thread for long syscalls is inefficient. (And a completely different topic than cond_waits)

Then why did you mention cond_waits?

Thread pools make it cheaper (or at least amortize the costs) and if the call is likely to block for a while anyway the real expense is essentially non-existant.

How would you know whether it is likely to do it or not? This is the whole point of threads that you do not need to know this\, and still can write effecient programs.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 03​:06​:16PM -0500\, Dan Sugalski wrote​:

As I demonstrated\, they are for a large (though not enormous) subset of things people want to do in signal handlers.

s/want to do/think they're limited to doing/;

Coming from a platform with very strong asynchronous leanings (VMS).

OS/2 also might have a nice System Exception model\, but this still does not work well in a presence of CRTL. Can you use CRT calls in this model?

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 04​:07 PM 1/12/00 -0500\, Ilya Zakharevich wrote​:

On Wed\, Jan 12\, 2000 at 03​:06​:16PM -0500\, Dan Sugalski wrote​:

As I demonstrated\, they are for a large (though not enormous) subset of things people want to do in signal handlers.

s/want to do/think they're limited to doing/;

Coming from a platform with very strong asynchronous leanings (VMS).

OS/2 also might have a nice System Exception model\, but this still does not work well in a presence of CRTL. Can you use CRT calls in this model?

Which model\, VMS' asyc system? Sure\, some of them. There are limits to what's acceptable\, but the limits are pretty broad. Generally you're not using the C RTL that much in an AST handler--most of the interesting work's done with system services. (But\, then\, VMS has a very rich set of system services\, so it's not a problem)

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 04​:19​:26PM -0500\, Dan Sugalski wrote​:

Which model\, VMS' asyc system? Sure\, some of them. There are limits to what's acceptable\, but the limits are pretty broad. Generally you're not using the C RTL that much in an AST handler--most of the interesting work's done with system services. (But\, then\, VMS has a very rich set of system services\, so it's not a problem)

Which is basically the same as with OS/2​: you cannot use any "interesting" CRT call\, and need to go into the "non-portable" mode.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 04​:22 PM 1/12/00 -0500\, Ilya Zakharevich wrote​:

On Wed\, Jan 12\, 2000 at 04​:19​:26PM -0500\, Dan Sugalski wrote​:

Which model\, VMS' asyc system? Sure\, some of them. There are limits to what's acceptable\, but the limits are pretty broad. Generally you're not using the C RTL that much in an AST handler--most of the interesting work's done with system services. (But\, then\, VMS has a very rich set of system services\, so it's not a problem)

Which is basically the same as with OS/2​: you cannot use any "interesting" CRT call\, and need to go into the "non-portable" mode.

Yeah\, but there really aren't any "interesting" CRTL calls. (Well\, except in the nastiest sense of the word interesting\, and those calls are best left alone anyway)

Not that this really matters for perl\, since the signal handlers won't be executing at interrupt time anyway...

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

Ilya Zakharevich (lists.p5p)​:

It is a virtue of a programmer\, but not in *another* programmer. ;-)

In short\, you wish to deny other people the chance to be virtuous? :)

-- Preudhomme's Law of Window Cleaning​:   It's on the other side.

[p5pRT]

From [Unknown Contact. See original ticket]

Simon Cozens writes​:

Ilya Zakharevich (lists.p5p)​:

It is a virtue of a programmer\, but not in *another* programmer. ;-)

In short\, you wish to deny other people the chance to be virtuous? :)

Do you imply that virtuousness is always a kind of lazyness?

Ilya

[p5pRT]

From @chipdude

According to Ilya Zakharevich​:

You can put Hanukka bush ornaments on anything. Most of the time the only reason Moliere syndrom appears is to hide the fact that the message is content-free. Even if not\, things may improve by removing ornaments.

Your point is well-taken.

On the other hand\, good design often comes down to taste and intuition\, which usually don't survive reductionist analysis.

Sometimes the only available alternative to being vague and indirect is leaving important things unsaid. Which is worse? -- Chip Salzenberg - a.k.a. - \chip@​valinux\.com   "He's Mr. Big of 'Big And Tall' fame." // MST3K

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Jan 12\, 2000 at 02​:22​:30PM -0800\, Chip Salzenberg wrote​:

You can put Hanukka bush ornaments on anything. Most of the time the only reason Moliere syndrom appears is to hide the fact that the message is content-free. Even if not\, things may improve by removing ornaments.

Your point is well-taken.

On the other hand\, good design often comes down to taste and intuition\, which usually don't survive reductionist analysis.

Sometimes the only available alternative to being vague and indirect is leaving important things unsaid. Which is worse?

Nobody will argue the role of metaphores and friends as vehicles of communication. I was considering situations when all that rides this channel is nil\, or when the communication could have been performed as well without these clutches.

Most of the time it boils down to the question of taste\, which is probably out of the realm of this particular forum.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

Most of the time it boils down to the question of taste\, which is probably out of the realm of this particular forum.

You're overreaching there. Taste certainly *does* count\, and it counts in this forum as much as in any--perhaps more so even\, sometimes. Good programming\, you see\, really is as much an art as it is a science or technical discipline--especially when it comes to matters of design\, which I believe was the topic in question. Careful attention to human factors is indispensable.

Oh\, taste might not count so much for all people at all times\, but it certainly does count here some of the time\, depending perhaps on who you are--by which I mean depending upon what you're trying to do. You might say that it's merely a matter of "taste" and therefore "out of bounds" that one should make a judgment call regarding complexity. You like complexity; that's your preference. I don't think it's a good thing\, and that's *my* preference (even though it's a design sin I myself am somewhat prone to falling into).

Now if you go look at Perl\, you'll see that shirking complexity and sweeping the horrors out from under the compiler's domain and into the poor programmer's cubicle--as you appear wont to do--is contrary to *Perl's* preference. So\, no\, I certainly don't believe taste in clarity and simplicity of design is out of bounds.

In particular\, when Larry himself is the one deciding that some proposed approach is too complicated to be added to Perl\, even though this is merely based upon his taste then it most certainly *does* lie within the proper purview of this forum. After all\, it was his taste that got us where we are today. So yes\, taste certainly does count\, especially when you're Larry. I hope that it counts for the rest of us\, too\, because if we disdain to consider taste\, then surely Perl's own taste will become unpleasant to the tongue.

Left to ourselves\, Ilya\, neither you nor I am ever going to create anything a tenth as nice as Perl. That's because both of us like things that are just too complicated to be useful and popular by the simple folk who get so much out of Perl. Although I harbor some hope that I fall into a complexity zone an order of magnitude simpler when compared to your own idiosyncratically tortuous predilections\, even so\, let me be the first to admit how often I miss the shortest and most diagonal route until this should be pointed out to me. But at least when this simple path *is* illuminated (sometimes in conjunction with a virtual cuff to the head to make me see the light)\, I'm more than happy to walk it. I wish it were likewise with you\, but I don't know how you'll ever overcome your own nature to complexify.

While I have your attention\, thank you very much for your misplaced attempt to condemn my writing as "mere prose". I cheerfully embrace your would-be term of disrespect and convert it instead into a matter of pride. Prose\, you see\, is something I rather like; I enjoy writing prose\, and I very much enjoy reading it. So I shall bear your accusation of prose not as a scarlet letter of shame upon my breast\, but as the shining badge of honor I have chosen to make it. After all\, without prose\, I would be left to write only equations\, which would annoy me to write\, or else to write only poetry\, which would annoy you even more to read than it would me to write.

Since you were apparently unable or unwilling to understand my point as it was delicately put to you previously\, clad as it was in gentle allegory to avoid damaging your feelings with so direct a statement as you are now about to read\, let me this time be perfectly clear. What I was saying was simply that you yourself tend strongly toward overdesign in the "way too darned complicated" way\, and that you should at every possible turn resist this temptation\, lest Perl be made into something fit for use only by those few others in the world afflicted with your own peculiar penchant for complexity.

--tom

  "Make is like Pascal. Everyone likes it so much they can't   resist changing it." --Dennis

[p5pRT]

From [Unknown Contact. See original ticket]

It's not that easy. Any significant task will require some complexity. One of the primary tasks of the designer is to squish the complexity around\, not only trying to reduce the total complexity but also shifting the complexity to the most painless area. The globally optimal solution may have more total complexity\, if such a thing could be measured\, because the complexity is forced into less harmful areas. In a client/server situation\, typically you want to pile more complexity onto the server when it saves the clients some trouble\, partly because there are more clients than servers (and each client is implemented independently)\, and partly because servers tend to run on beefier hardware (complexity and performance tend to be inversely correlated.)

I don't think Ilya is enamored of complexity\, I just think that he weights things differently. He'd rather remove odd special cases that make the perl implementation and documentation more complex\, and add features that allow users to get their jobs done more straightforwardly; TomC would rather place more of the complexity burden of backwards compatibility on the perl core and make life simpler for people who know the existing perl and have written thousands of working scripts. From either's perspective\, the other seems to be a mad lunatic bent on destroying perl for some strange diabolical and egomaniacal purpose. The rest of us know they're both right\, but that somehow the combination results in a perl that just gets better and better\, and only rarely worse.

- Your resident anthropologist

If I have offended anyone by the above characterizations\, I do most humbly and deeply apologi... nah\, screw it\, neither of you knows where I live.

[p5pRT]

From [Unknown Contact. See original ticket]

Joshua N Pritikin \joshua\.pritikin@​db\.com writes​:

On Wed\, Jan 12\, 2000 at 11​:01​:16AM +0000\, Tim.Bunce@​ig.co.uk wrote​:

My (vague) impression is that that work fragmented with one group adding features and others being unhappy that there were too many features. I think it's lost direction and consensus support. Sadly.

That's news to me. Granted\, there was heated discussion for a few months but I believe most folks are now mostly satisfied with the design and implementation. Graham\, Nick\, Gisle and others\, feel free to correct me or forever hold your peace. ;-)

I am in both camps - on the one hand it is my _impression_ that Event needs more functionality before I can use it to replace the Tcl event C code that is at the core of perl/Tk. On the other hand I feel that what we have is over complex. But I have not actually tried to use Event in anger yet so it is not really fair to judge.

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. (Multiple threads are almost mandatory as work-rounds to Win32 issues.) Thus Event should probably use the C level mutex stuff from the perl core where appropriate. That said until thread support in the core settles down I can understand Joshua's reluctance to mess with threads.

I have little idea about Win32.

Which is another weakness. If Event offered a solution to perl/Tk's Win32 woes I would be much more motivated to use it.

Personally\, I am not interested in doing a port. No volunteer has stepped forward so perhaps we can strike a deal with Microsoft to commission the work. At least I can parrot from those more knowledgable that the Win32 model is *significant* different than Unix.

It may be so different that the current abstractions make no sense.

I think we have a nasty case of chicken-and-egg here​:

Event is not finished till it can do Win32. Cannot do Win32 without threads. Threads seem to need Event ...

Thus I suspect that what it really needs is ActiveState (e.g. Sarathy)\, to need something working ...

-- Nick Ing-Simmons

[p5pRT]

From [Unknown Contact. See original ticket]

Larry Wall \larry@​wall\.org writes​:

Fisher Mark writes​: ​: (Hmmm. I wonder what would be the performance of a text editor written in ​: Perl?)

Depends on how you implement your character insertion\, your screen refresh\, and your various incestuous internal hooks. But mostly it depends on whether you call it pim or pemacs. :-)

The main drawback of ptked is the load time ;-)

-- Nick Ing-Simmons

[p5pRT]

From @gsar

On Sun\, 16 Jan 2000 15​:37​:16 GMT\, Nick Ing-Simmons wrote​:

Personally\, I am not interested in doing a port. No volunteer has stepped forward so perhaps we can strike a deal with Microsoft to commission the work. At least I can parrot from those more knowledgable that the Win32 model is *significant* different than Unix.

It may be so different that the current abstractions make no sense.

I think we have a nasty case of chicken-and-egg here​:

Event is not finished till it can do Win32. Cannot do Win32 without threads. Threads seem to need Event ...

Thus I suspect that what it really needs is ActiveState (e.g. Sarathy)\, to need something working ...

I haven't had time to do anything serious with the Event stuff\, but another thing that needs to happen before Windows can do Event-like things properly is to rewrite the CRT abstraction layer (or at least the parts that go into a wait state) to make them capable of nonblocking waits/asynchronous events.

Let's keep this on the agenda for the 5.7.x development series.

Sarathy gsar@​ActiveState.com

[p5pRT]

From [Unknown Contact. See original ticket]

On Sun\, Jan 16\, 2000 at 03​:37​:16PM +0000\, nick@​ing-simmons.net wrote​:

Joshua N Pritikin \joshua\.pritikin@​db\.com 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. (Multiple threads are almost mandatory as work-rounds to Win32 issues.) Thus Event should probably use the C level mutex stuff from the perl core where appropriate. That said until thread support in the core settles down I can understand Joshua's reluctance to mess with threads.

Yes\, that is the situation. I am happy to add whatever thread support is deemed appropriate as soon as what is appropriate isn't a wildly moving target.

-- "Never ascribe to malice that which can be explained by stupidity."   via\, but not speaking for Deutsche Bank