deavmi/birchwood
deavmi/birchwood
1
0
Fork 0
mirror of https://github.com/deavmi/birchwood synced 2024-09-20 09:03:29 +02:00
Code Issues Releases Activity

Receiver

Browse Source 
- Removed `hasEnsured` (commented-out already)
- Call `ensure(this)` in constructor
- Removed TODOs relating to ensurance

Sender

- Removed `hasEnsured` (commented-out already)
- Call `ensure(this)` in constructor
- Removed TODOs relating to ensurance
This commit is contained in:
Tristan B. Velloza Kildaire 2023-06-25 17:01:52 +02:00
parent 2481ef88db
commit 125bb613a7
2 changed files with 4 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
source/birchwood/client/receiver.d
View File

@ -48,7 +48,6 @@ public final class ReceiverThread : Thread
* to be processed and received
*/
private Event receiveEvent;
// private bool hasEnsured;
/**
* The associated IRC client
@ -67,7 +66,8 @@ public final class ReceiverThread : Thread
super(&recvHandlerFunc);
this.client = client;
this.receiveEvent = new Event(); // TODO: Catch any libsnooze error here
this.recvQueueLock = new Mutex();
this.recvQueueLock = new Mutex();
this.receiveEvent.ensure(this);
}
// TODO: Rename to `receiveQ`
@ -89,10 +89,6 @@ public final class ReceiverThread : Thread
/* Unlock queue */
recvQueueLock.unlock();
// TODO: Add a "register" function which can initialize pipes
// ... without needing a wait, we'd need a ready flag though
// ... for receiver's thread start
/**
* Wake up all threads waiting on this event
* (if any, and if so it would only be the receiver)
@ -116,21 +112,6 @@ public final class ReceiverThread : Thread
{
// TODO: We could look at libsnooze wait starvation or mutex racing (future thought)
// // Do a once-off call to `ensure()` here which then only runs once and
// // ... sets a `ready` flag for the Client to spin on. This ensures that
// // ... when the first received messages will be able to cause a wait
// // ... to immediately unblock rather than letting wait() register itself
// // ... and then require another receiveQ call to wake it up and process
// // ... the initial n messages + m new ones resulting in the second call
// if(hasEnsured == false)
// {
// receiveEvent.ensure();
// hasEnsured = true;
// }
// TODO: See above notes about libsnooze behaviour due
// ... to usage in our context
try
{
receiveEvent.wait();
@ -152,9 +133,7 @@ public final class ReceiverThread : Thread
}
continue;
}
/* Lock the receieve queue */
recvQueueLock.lock();

28
source/birchwood/client/sender.d
View File

@ -40,7 +40,6 @@ public final class SenderThread : Thread
* to be processed and sent
*/
private Event sendEvent;
// private bool hasEnsured;
/**
* The associated IRC client
@ -60,6 +59,7 @@ public final class SenderThread : Thread
this.client = client;
this.sendEvent = new Event(); // TODO: Catch any libsnooze error here
this.sendQueueLock = new Mutex();
this.sendEvent.ensure(this);
}
// TODO: Rename to `sendQ`
@ -81,10 +81,6 @@ public final class SenderThread : Thread
/* Unlock queue */
sendQueueLock.unlock();
// TODO: Add a "register" function which can initialize pipes
// ... without needing a wait, we'd need a ready flag though
// ... for sender's thread start
/**
* Wake up all threads waiting on this event
* (if any, and if so it would only be the sender)
@ -92,7 +88,6 @@ public final class SenderThread : Thread
sendEvent.notifyAll();
}
/**
* The send queue worker function
*/
@ -100,24 +95,10 @@ public final class SenderThread : Thread
{
while(client.running)
{
// // Do a once-off call to `ensure()` here which then only runs once and
// // ... sets a `ready` flag for the Client to spin on. This ensures that
// // ... when the first sent messages will be able to cause a wait
// // ... to immediately unblock rather than letting wait() register itself
// // ... and then require another sendQ call to wake it up and process
// // ... the initial n messages + m new ones resulting in the second call
// if(hasEnsured == false)
// {
// sendEvent.ensure();
// hasEnsured = true;
// }
// TODO: We could look at libsnooze wait starvation or mutex racing (future thought)
/* TODO: handle normal messages (xCount with fakeLagInBetween) */
// TODO: See above notes about libsnooze behaviour due
// ... to usage in our context
try
{
sendEvent.wait();
@ -141,13 +122,6 @@ public final class SenderThread : Thread
}
// TODO: After the above call have a once-off call to `ensure()` here
// ... which then only runs once and sets a `ready` flag for the Client
// ... to spin on
/* Lock queue */
sendQueueLock.lock();