in reply to Re^6: Your main event may be another's side-show.
in thread Your main event may be another's side-show.

Xwindows? What is that? Some sort of GUI thingy? Didn't I specifically exclude GUIs?

So after all, your complains are not about frameworks in general, but about those that are introduced in CPAN modules? Then should we also exclude the frameworks that are based on underlying C libraries (like glib)? :)

Show me AnyEvent or Event or Coro, or POE or any other Perl event framework running succesfully within a ithreaded perl program. Betcha can't.

I can't. I've never used any of those. I've created my own :) But it does not mean that it is not possible. It just means that I've never tried, neither those frameworks nor ithreaded perl. (But I've done this with C language programs). And of course it does not mean that those frameworks are BAD THING. They are only not suitable for you, but you don't have to use them. So they are forcing nothing on you.

As a side note. Even though I haven't tried it, I do believe that it shouldn't be hard as long as the socketpair (or pipe) command in perl works. Something like 

sub event_handler
{
    if(time_taking_task())
    {
        #socketpair(MY, HIS)
        pipe(MYIN, THROUT);
        pipe(TRHIN, MYOUT);
        check_for_reading(MYIN, \&info_from_thead);
        launch_thread(\&my_thread);
    }

}

sub info_from_tread
{
    sysread(MYIN, $var);
}

sub my_thread
{
 # do some long work
 print THROUT "Give more data\n";
 sysread(THRIN, $data);
}

[download]

Replies are listed 'Best First'.
Re^8: Your main event may be another's side-show.
by BrowserUk (Patriarch) on Oct 21, 2010 at 10:58 UTC
    Then should we also exclude ...

    You (and all the others that sit behind your royal we), should not exclude anything that you individually or collectively find useful. I described my distaste for frameworks, and my reasons. It is up to anyone else to reach their own conclusions.

    I can't. I've never used any of those. I've created my own :) But it does not mean that it is not possible.

    Oh, it is possible to use event-driven logic within a threaded application. For example, Tk's event loop runs just fine within a thread(*). The same is true of Prima & Wx. And OpenGL. And Win32::GUI. And any event loop constructed around select, even when encapsulated and simplified through the use of IO::Select work fine in threads also.

    (*)Though you do have to be careful not to try using tk objects across multiple threads.

    So there is no fundamental incompatibility between threading and event-driven programming.

    But--and this is the whole point--all of the above are libraries! Not frameworks. And it demonstrates exactly why I like the former and dislike the latter.

    With libraries, I call whichever library best serves my needs, whenever I want, and in whatever combination I want.

    With frameworks, I have to try and remotely manipulate them into calling me at the appropriate time to do whatever needs to be done, and they fall in a heap around my ears if I do something they don't like.

    (Well written) Libraries good. Frameworks suck! (But each to their own:)

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      But--and this is the whole point--all of the above are libraries! Not frameworks

      Well. I guess we (I mean you and I) have different understanding on what a framework is. I would consider the Tk's event loop a part of "framework". But you consider it a "library" :)

      Since the subject resulted in just personal dislike of certain modules from CPAN, then I don't see any reason to argue about this. I'm trying to respect personal dislikes :)

[reply]
        I guess we (I mean you and I) have different understanding on what a framework is.

        The best online definition I could find of a framework in this context is at http://parlab.eecs.berkeley.edu/wiki/patterns/glossary which is fairly authoratative:

        Framework: A framework is a software environment organized around a software architecture that allows for programmer customizations only in harmony with the software architecture

        Which mirrors the kind of crtisisms I've been levelling at them when I've said: They proscribe the entire architecture of your application; and: They prevent you from using all the tools in your toolbox.

        My own definition is a simple test. Do I call them; or do they call me? The former is a library, the latter a framework. (That line can be blurred.)

        I don't see any reason to argue about this. I'm trying to respect personal dislikes :)

        Agreed! One man's squishy, slimey, salty yuk, is another man's caviare :)

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations