Slick + Multi-threading...

So I was having a discussion with the other programmer on my game and he stated that Slick is mono-threaded. I said “yeah, which means that we need to implement multi-threading ourselves”.

He thinks it’s a bad idea.

I don’t see any other way to do a multi-player game without it being multi-threaded… for the simple fact that you can’t halt the game for networking issues, and thus should handle all networking in a seperate thread. Same thing with the user interface…

What are your guys thoughts? :slight_smile:



for sure you can’t listen to sockets in the main thread. I invite you to have a look at the excellent Kryonet library done by Nate.

It creates a thread for listening to the incoming messages, the callback is executed also in this thread but you can just add incoming messages to a ConcurrentLinkedQueue and read this queue from the main thread at each loop iteration ( that’s what I’m doing for my game ).

Kryonet handles automatically serialization of messages using Kryo, and is really easy to use/setup :slight_smile:

Most graphics libraries are single-threaded, no getting around that. But your colleague’s also right, doing your own concurrency from scratch using just threads is usually a bad idea. Try instead something higher level like the stuff in java.util.concurrent or an actor system like Kilim or Jumi or one of the ones mentioned in this paper (it starts off with scala examples but don’t worry, the libraries it compares are mostly java).

If it’s networking, consider using netty instead of thread-based concurrency. And so on. Moral of the story is: concurrency is tricky business, so use a library.

Thanks for your help guys, I will definitly try to implement any threads I’ll use via library.

-Pickle :slight_smile: