if sender thread was started, one have to call join it - even when
thread function was normally returned

Instead of starting every new thread for new operation - reuse same
thread which was started during first send operation.

Also take care that such dedicated threads correctly stopped when
WSHandler is destroyed

Only in such mode multithreading is allowed. 
In async mode one can meaningfully use send completion callback.
Default mode is synchronous (as before), which allows to use handler
only from main thread

Before one could submit as many operation as one wants to the websocket.
In case of longpoll socket this lead to extra queue, which was not
controlled by the user. 

Now each send operation is confirmed by callback. Only after such
callback next send operation via websocket is allowed. Queue is
organized externally (like in TWebWindow). 

For the longpoll engine this simplify internal logic and avoids queueing

Now no queues are allowed, all operation are confirmed by WS handler

Now one can directly register WS handlers to THttpServer
If allowed, handlers can be precessed directly in the civetweb threads
without involving of THttpServer thread at all. 
This allows to run many connections for many different web widgets
absolutely independent from each other - there are no one bottleneck in
http thread (or any other main thread)

web socket engine should support this (default off) and
web socket handler have to allow this

In case of long poll engine requests should be holded until next send
operation from the server starts. To correctly resolve ownership,
shared_ptr should be used on all stages of processing

One could send now binary messages viw websockets, 
which result as Blob objects on JavaScript side. 
Also combined send of string header and raw buffer will be supported.
For special engines (like longpoll) this will be handled in single
request.

Now it is fully internall class, which should be used only by framework.
Use THttpWSHandler to work with websockets

remove inheritance from TNamed, 
change signature of PreviewData() and PostProcess() methods

In heavy data traffic let reduce number of requests by factor 2. 
Before separate request was required to send data and to receive data

Now all WS connections and correspondent THttpWSEngine instances
preserved in the THttpWSHandler. User only works with WS Id (UInt_t) and
use it to accept connection, close connections, send data via connection

git-svn-id: http://root.cern.ch/svn/root/trunk@19826 27541ba8-7e3a-0410-8455-c3a389f83636

git-svn-id: http://root.cern.ch/svn/root/trunk@19825 27541ba8-7e3a-0410-8455-c3a389f83636

git-svn-id: http://root.cern.ch/svn/root/trunk@4509 27541ba8-7e3a-0410-8455-c3a389f83636

in TROOT could cause problems since at that point not all needed classes
are known to CINT.


git-svn-id: http://root.cern.ch/svn/root/trunk@2034 27541ba8-7e3a-0410-8455-c3a389f83636

system loads libCore.so. Also removed TROOT.h in several programs.


git-svn-id: http://root.cern.ch/svn/root/trunk@2028 27541ba8-7e3a-0410-8455-c3a389f83636

On Windows, otherwise, the call to CleanUpROOTAtExit is done after all class destructors
have been called.


git-svn-id: http://root.cern.ch/svn/root/trunk@1821 27541ba8-7e3a-0410-8455-c3a389f83636

inside the main program. This avoids problems with the unpredicted order of destructors
on several machines.


git-svn-id: http://root.cern.ch/svn/root/trunk@1808 27541ba8-7e3a-0410-8455-c3a389f83636

which included commits to RCS files with non-trunk default branches.


git-svn-id: http://root.cern.ch/svn/root/trunk@3 27541ba8-7e3a-0410-8455-c3a389f83636