1. Well, the problem is not that that one SELECT is blocking all the other SELECTs. MyISAM handles concurrent SELECTs without a problem with a table lock. It's that you also have an UPDATE, which has to wait on the long running SELECT. All the other SELECTs, which were issued after the UPDATE, now have to wait until the UPDATE finishes. However, the UPDATE won't even start until the long-running SELECT finishes. Everything is basically fine and dandy until you decide you want to change the table, and then a domino effect occurs. This is the result of table locking.
You can set LOW_PRIORITY for the UPDATE (UPDATE LOW_PRIORITY `dplogin_accounts`), which will try to make MySQL push back the update until there are no SELECTs. The only issue here is that, if the table is very busy with SELECTs, the UPDATE might be pushed back for a very long time.
Another option is to split the table. For columns that get updated more often but read less often, you can move them into a second table.
You can also switch to InnoDB in order to use automatic row-level locks instead. That will slow down queries that select from multiple rows though, because of the overhead of locking and unlocking each individual row.
Or another option is to "hold" all the UPDATE queries manually. You can have a script sit around to fire all the UPDATE queries rapidly at the same time at some interval. That means that the data will be a bit stale for some time, but then UPDATEs won't be interspersed between the long-running queries. The blocks will still occur with this option, but they will be less frequent.
The best solution, however, is to make that SELECT quick.
2. Persistent connections tend to do that, and I don't think they offer much of a benefit. If your database is on a different system and you're connecting via TCP, then perhaps you may want to use persistent connections.