[jcifs] threading

[Michael B. Allen]

On Sat, 22 Feb 2003 23:59:09 -0600
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:

> On Sun, Feb 23, 2003 at 12:31:06AM -0500, Dan Dumont wrote:
> > That's fine with me, perhaps I did not make my intentions clear.  I
> > don't mind if it blocks the thread.  What I do mind is that it blocks
> > all other threads trying to connect also.
> > 
> > The whole program locks up while I wait for one thread to connect.  
> 
> That's because blocking occurs at the host OS process level.  I *believe*
> that when a Java thread performs an operation that causes the JVM to call
> a blocking system call, the entire JVM instance (which exists as a single 
> OS thread) will block.

Older JVMs like Java 1.1 days used to do this. Any good VM does not do
this. Threads are implemented natively using OS provided primatives.

> This may depend upon the implementation, since some implementations may 
> behave differently (that is, they may implement threading differently).
> 
> I am doing a bit of guessing here, based on my earlier experience with 
> blocking DNS lookups under Java (many years ago).

Many years ago this was true. Not anymore.

> Here's an interesting reference I stumbled upon:
> 
>   http://www.cs.berkeley.edu/~mdw/proj/java-nbio/

Java 1.4 has a non-blocking IO package. But it's not really for
getting around the problem you describe above. It's really more about
performance. For example jCIFS creats "QueryThread"s to do NetBIOS name
lookups concurrently. That sort of thing is just plain UGLY. This is
what the non-blocking IO package is for. Never used it but we eventually
should because it would be a huge performace boost.

Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.