FortKnox's Journal: A Question for the Java Guys...

OK, I want to make a TCP server that accepts multiple clients, but I want it to be able to do processing during the idle time.

Now, I've been reading up on Java1.4 that has non-blocking I/O which is wonderful for elminating the threads in a multi-connect TCP server. But, the select() method still waits for activity, and I want the server to do other computing while there isn't activity (making a persistant-world MMORPG if you must know). I'm trying to avoid threads, so I start looking at the other Selector methods.
My question is, does the selectNow() method emulate the poll() function in C (eg - will it hold onto the activity in a buffer and wait until I call it next to dump it onto me)??

I already exhausted google for a while, and here's the javadoc for Java1.4. The selector class is in java.nio.channels. After reading the doc, maybe I'm thinking this all wrong. Anyone have any ideas on how to simulate the poll() function?

Addendum: Onjava has an article that has a snippet example of how the new nio classes work (see #3 on the page).

Why avoid threads?

[norwoodites]

Why would anyone try to avoid threads is beyond me, especially in Java?

Re:Why avoid threads?

[FortKnox]

Well, threads open up headaches. Passing things between threads open up migranes.
Threads require syncronization. Do you know which collections in Java are syncronized and which are not? I think the majority of the collection class is unsyncronized. And the possibilities of deadlock, and how one thread has difficulty understanding what is going on in another thread. Multithreading is best avoided, if you ask me.

Re:Why avoid threads?

[Sunda666]

the tcp listener thing must be done with threads. Believe me, I do that for a living. Without threads, the listener have to do other things than listening, and the server becomes an unresponsive piece of shit.
i know dog shit about java (i use perl and c/c++), but threads are pretty easy to implement (atleast in UNIX, but I remember they being easy in winblows nt with c++ too, back in the day).
Well, if you still dont want threads, do the following:

put all the code (yuck) in a loop that starts with a nonblocking select (timeout = 0), do your processing if the select returned 0, or read/accept from the file descriptors the select returned. This works in UNIX, dunno about windows, but probably will work too since 2k's tcp is mostly BSD-ish.

Regards.

Re:Why avoid threads?

[mirabilos]

Probably in order to avoid Microsoft-isms such
as "quick and dirty but works well (for me)"
programmes and unreadable code.

Probably because people have been impressed by
the clearness of the OpenBSD code (not the parts
which haven't been rewritten, or portable stuff
such as OpenSSH-portable).

Why not thread?

[glh]

I did a quick and dirty threaded listener using in Java (later ported to c#). It worked pretty well.. I could e-mail the source code if you want (assuming I can dig it up). I know threads aren't fun to manage but it might be the best way to do it.

Hmm

[JMZero]

I think you definitely want a thread that's just buffering input. If you're attempting scalability, you're going to need to take control of this at some point anywho. But that's just $.02 from someone who has never done anything like this (never for more than a couple users at a time).