I have an idea. Instead of using direct
the packet service, instead use interfaces. Basically what I can do instead
is have a
OutputDatagrams. Of course the datagrams
can be layered on top of input and output streams, but the main purpose of
it would be to encode and decode accordingly as such. Of course this will
need a slight adjustment because packets may need to have their keys encoded
into them for the sending and receiving to work properly. But basically it
will allow for the transport to be implemnted with other means rather than
just basic streams. But at least the initial implementation will use basic
Would there be lots of contention if I had a global static packet farm? I could have a volatile int field so that there are multiple packet farms which are handled in some kind of sequence.
Also, it would be best to have an alternative class instead for responses so that way the receiving end of the packet stream does not need to keep references around. But it still does for sending packets. But actually no it does not because the locking would be handled by the datagram output so it no longer needed. The response handler can just be given the output datagram.
Okay so switching to the datagrams and having other interfaces handle locking
will basically make
PacketStream really simple.
The code I am refactoring definitely looks much nicer now compared to before.
So the packet stream for the most part has been refactored, it seems a bit faster now. I suppose especially since there are less locks there is less contention among threads.
I definitely have a dead lock.
Okay, so I get why it deadlocks. Basically I have a single thread which handles events. Then I send another request to handle that request, which does not work properly. So basically what I need to do is to make a thread which can handle requests when they come in.
So I am going to need a packet stream thread pool which can handle tasks. The
thread pool can be global though and internal, or at least one per
PacketStream. The kernel has two packet streams and each client will have a
single packet stream to the server. So basically when an event needs to be
handled, a new thread should be created or recycled to run and then respond
to the request.
Some systems have a limit on the number of threads which can run at once though. So I will definitely need to make some kind of pseudo thread system because SquirrelJME will require quite a number of threads to work properly. This means that the more requests being done, the higher the CPU load will be, so this will definitely need to be considered.