I know that Comet long polling are bad for Web servers because they occupy one thread per connection. So you cannot have a lot of users with persistent connections or your web server will crash.
Is this the same with web sockets in HTML 5?
How could this solve the resource problem if it occupies one thread too per persistent connection?
...because they occupy one thread per connection
This assumption is totally untrue. See the answer I gave here for more info. It is (for instance) entirely possible to use IAsyncHttpHandler in IIS to perform long-polling, without using a thread per client.
Spender is correct, only shitty web servers (e.g. Apache with mpm_worker or mpm_prefork) use a thread/process per connection.
A smart Comet or Websockets gateway (I wrote such one not long ago) will have an event-driven architecture - either based on the Proactor (with a fixed pool of threads) or Reactor (single-threaded) patterns. Long-polling should be done over keep-alive HTTP connections (for the browsers which support that - about 99% of them), in which case it will have similar performance/scalability characteristics as Websockets.