in reply to threads and their alternatives
in thread Alternatives to threads for maintaining GUI app responsiveness

I like to know the pros and cons of possible solutions.

Threads are built-in, simple, portable and are working for you now.

The rest are non-portable add-ons, with huge learning curves, that produce complicated, hard to maintain code.

And they don't have a solution to fundamentally blocking apis like DBI.

Your question might make some sense if you had specific problems with the threaded solution, but it seems you are allowing the validity of your working code to be questioned on the basis of its 'coolness' with a particular group of people, who "don't like threads" but can't explain why. That's not good reasoning.

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.

Replies are listed 'Best First'.
Re^2: threads and their alternatives
by Corion (Patriarch) on Sep 30, 2011 at 20:23 UTC

    As an aside, AnyEvent is fairly portable and has a solution to blocking APIs like DBI. Whether that solution is really a good solution stands to debate - it spawns an external process which executes the fetch and then passes the results back via IPC. In principle, this idea isn't all bad, except that I wouldn't use one external process per query but a separate thread that does all database interaction.

[reply]
      AnyEvent is fairly portable

      Really? Does it work with files and pipes under Windows?

      Does AnyEvent::DBI work on Windows? Cos you certainly wouldn't think so looking at the source:

         my $pid = fork;

   if ($pid) {
      # parent
      close $server;
   } elsif (defined $pid) {
      # child
      my $serv_fno = fileno $server;

      if ($self->{exec_server}) {
         fcntl $server, &Fcntl::F_SETFD, 0; # don't close the server s
+ide
         exec {$^X}
              "$0 dbi slave",
              -e => "require shift; AnyEvent::DBI::serve_fd ($serv_fno
+, $VERSION)",
              $INC{"AnyEvent/DBI.pm"};
         POSIX::_exit 124;
      } else {
         ($_ != $serv_fno) && POSIX::close $_
            for $^F+1..$FD_MAX;
         serve_fh $server, $VERSION;

         # no other way on the broken windows platform, even this leak
+s
         # memory and might fail.
         kill 9, $$
            if AnyEvent::WIN32;

         # and this kills the parent process on windows
         POSIX::_exit 0;
      }
   } else {
      croak "fork: $!";
   }

   $self->{child_pid} = $pid;

   $self->_req (
      ($self->{on_connect} ? $self->{on_connect} : sub { }),
      (caller)[1,2],
      req_open => $dbi, $user, $pass, %dbi_args
   );

   $self
}

      [download]
      has a solution to blocking APIs like DBI. ... it spawns an external process which executes the fetch and then passes the results back via IPC.

      I guess I could have said "don't have a good solution", but I don't consider starting a new process for each query and then having to squeeze potentially large amounts of structured data through a byte stream, a solution worthy of the name.

      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]
[d/l]

        So far, I've only used AnyEvent for TCP and timers, and that works well on Windows. I suppose it works well enough with pipes, at least it has lots of Win32-specific code to create a selectable pipe on Win32. I haven't used AnyEvent::DBI, as I'd use a thread instead of an external process if I had the need to do asynchronous DB access on Windows, and the code looks as if it uses features like selectable filehandles, that just aren't conveniently available on Windows...

[reply]
Re^2: threads and their alternatives
by zwon (Abbot) on Oct 02, 2011 at 06:30 UTC
    with huge learning curves, that produce complicated, hard to maintain code.

    Can't agree with this statement, I had to work with some projects with POE and AnyEvent and it wasn't especially hard to learn and maintain. On the other hand I will not call threads simple, as most people (I'm judging by code I had to work with) either had no idea that they need to lock shared variable before accessing it at all, or are not able to implement it properly.

[reply]

      Would you be up for the challenge of producing a demo solution for the OPs described problem using one of the event-based frameworks?

      If so, I'll do a threaded version and we could compare them for complexity.

      If you're up for it, we could start with a simple GUI in Tk or GTK that presents data as a list -- zentara has posted many examples we could use as a starting point -- and then we add a few buttons that are used to control which records are SELECTed from a simple SQLite database using an SQL query via DBI.

      Contrasting two working solutions would be far more useful that contrasting our opinions I think.

      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]
        Would you be up for the challenge

        No way, I have better ways to spend Sunday. BTW, in this particular case I would probably use separate process for GUI (or even thread, I'm not a bigot), I don't see the reason you're trying to limit me with event-based solution.

[reply]

In Section Seekers of Perl Wisdom