can remove lock in Batch if limit is 1

[chitandahua]

let mut limit = 0x100;
if let Some(cmd) = &config.command {
    if !cmd.in_batch_mode() && config.threads > 1 {
        // Evenly distribute work between multiple receivers
        limit = 1;
    }
}

when threads > 1 , the limit is 1
and then when BatchSender send every time only send 1 Batch(because when items.len() == 1, the batch will be sent)
this means in that situation, can we remove the lock?
avoid everytime alloc mutex and lock，just send the item directly without Arc<Mutex<>>?

[tmccombs]

when threads > 1 , the limit is 1

only if the --exec option is used.

config.command is only Some if --exec or --exec-batch is used, and if --exec-batch is used, then cmd.in_batch_mode() would be true. (--list-details is basically equivalent to an --exec-batch).

this means in that situation, can we remove the lock?

I think it would be possible to do that, but it would probably make the code more complicated. The simplest way to do it would probably be to make BatchSender an enum, which would then need to check the type of the enum every time an element was sent to determine if it should use the batch, or just send the item. Then the receive function would have to be refactored somehow to account for the fact that there are two possible message types.

[chitandahua]

Thanks for reply. Yeah, you are right, only when --exec option set.
I think maybe we can make the Batch to enum, maybe like this? just for example

enum Batch {
    Lock(Arc<Mutex<Option<Vec<WorkerResult>>>>),
    NonLock(Option<Vec<WorkerResult>>), // if the limit is always 1 and not change, may use Option<WorkerResult>? or even remove Option?
}

when new Batch, transfer the limit and use Vec::with_capacity(limit)
change into_iter for Batch and send for BatchSender, receive function no need to change
this can improve performance when --exec option set, but for other situation, add new match, may need a lot of test.
Whether to do it or need detailed evaluation