Why does golang-sdk required select to handle signals while java-sdk doesn't

Community Support
1

I am using both go-SDK and java-SDK. I find they 2 are handling signals differently.

In golang, if I add a receive callback to the selector and do not call the selector. select, the callback will not be called and the signals are unhandled.

testSelector.Select(ctx) // this is required for the AddReceive to be called, merely register the callback does not help

func createTestSelector(ctx workflow.Context) workflow.Selector {
	logger := workflow.GetLogger(ctx)
	submitSelector := workflow.NewSelector(ctx)
	submitChannel := workflow.GetSignalChannel(ctx, SINGALCHANNEL_TEST)

	submitSelector.AddReceive(submitChannel, func(ch workflow.ReceiveChannel, more bool) {
		var val string
		isChClosed := ch.Receive(ctx, &val)
		logger.Debug("[test] received:", val, isChClosed)
	})
	return submitSelector
}

But in java, a simple @ SignalMethod suffices to handle the signals.

So why does golang add another level of requirement for signal handling?

2

You don’t need to use a Selector to read a message from a Channel.

ch.Receive(ctx, &val)

is enough. The selector is needed only when you want to wait on multiple Channels and/or Futures.

Each SDK tries to stay as native as possible to the language semantic. In Go, channels are the way to deliver messages to goroutines. In Java, callbacks are the more natural way to deliver them.