MUD-Dev
mailing list archive

Other Periods  | Other mailing lists  | Search  ]

Date:  [ Previous  | Next  ]      Thread:  [ Previous  | Next  ]      Index:  [ Author  | Date  | Thread  ]

[MUD-Dev] Re: Java I/O and threads.



cynbe#muq,org (cynbe#muq,org) spake thusly:
> On 25-Jan-99 Jo Dillon wrote:
> >   Not necessarily - it depends on your hardware and OS. Java's designed
> > to use lots of threads so it's not too much of a worry.
> But Java is a resource pig at the best of times :( :( :(.

  I'm fully aware of that. I maintain a 30,000 line Java applet for
a living (among other things).
 
> I just came off a year with a company (www.activerse.com) trying to produce
> a Java application (Ding!) to compete with C applications (ICQ), and it was
> very discouraging.
> 
> Be aware that, for example, a seven-char string will eat over 100 bytes of
> ram.  Many muds use small strings heavily, so this can be nearly lethal if
> resource usage is any sort of concern at all.

  Well, that depends on the system.
 
> The Java GUI libraries, at least, also tend to be rather un threadsafe, in
> ways that vary wildly from platform to platform.  I can't speak for the other
> Java libraries, but I'd be inclined to suspect the worst until demonstrated
> otherwise.

  I've had no problems with the 1.1 AWT. Swing is intentionally designed
not to be threadsafe, I believe. But surely the whole point is moot with
a Java /server/.
 
> I did look at the no-select()-in-Java problem, and as far as I can tell, 
> there
> is indeed no alternative to a thread per active socket.  I'm less optimistic
> than Jo that all platforms will handle this nicely, however.  
> To put it mildly.

  Well, I didn't say it'd be 'nicely'. Java isn't my ideal server 
implementation language either. But merely having lots of threads isn't
likely to be the biggest problem.

-- 
	Jo






Other Periods  | Other mailing lists  | Search  ]