在注册表模式中异步回复

huangapple go评论82阅读模式
英文:

async reply in registry pattern

问题

我正在学习Go语言,并且想要探索一些模式。

我想要构建一个Registry组件,它维护一些东西的映射,并且我想要提供对它的序列化访问:

目前我得到了如下的代码:

type JobRegistry struct {
  submission chan JobRegistrySubmitRequest
  listing chan JobRegistryListRequest
}

type JobRegistrySubmitRequest struct {
  request JobSubmissionRequest
  response chan Job
}

type JobRegistryListRequest struct {
  response chan []Job
}

func NewJobRegistry() (this *JobRegistry) {
  this = &JobRegistry{make(chan JobRegistrySubmitRequest, 10), make(chan JobRegistryListRequest, 10)}
    
  go func() {
    jobMap := make(map[string] Job)
        
    for {
        select {
        case sub := <- this.submission:
            job := MakeJob(sub.request) // ....
                
            jobMap[job.Id] = job
            sub.response <- job.Id
                
        case list := <- this.listing:
                
            res := make([]Job, 0, 100)
            for _, v := range jobMap {
                res = append(res, v)
            }
            list.response <- res
                
        }

        /// case somechannel....
     }
   }()
    
   return
}

基本上,我将每个操作封装在一个结构体中,它携带参数和一个响应通道。

然后我为最终用户创建了辅助方法:

func (this *JobRegistry) List() ([]Job, os.Error) {
	res := make(chan []Job, 1)
	req := JobRegistryListRequest{res}
	this.listing <- req
	return <-res, nil // todo: 处理超时等错误
}

我决定为每种类型的请求使用一个通道,以确保类型安全。


我看到这种方法存在的问题有:

  • 大量的样板代码和许多需要修改的地方,当某些参数/返回类型发生变化时

  • 必须做一些奇怪的事情,比如创建另一个包装结构体,以便从处理程序goroutine中返回错误。(如果我理解正确,Go语言中没有元组,也没有办法在通道中发送多个值,比如多值返回)

所以,我想知道这一切是否有意义,还是回到传统的锁机制。

我相信有人会找到一些聪明的方法来使用通道解决这个问题。

英文:

I'm learning go, and I would like to explore some patterns.

I would like to build a Registry component which maintains a map of some stuff, and I want to provide a serialized access to it:

Currently I ended up with something like this:

type JobRegistry struct {
  submission chan JobRegistrySubmitRequest
  listing chan JobRegistryListRequest
}

type JobRegistrySubmitRequest struct {
  request JobSubmissionRequest
  response chan Job
}

type JobRegistryListRequest struct {
  response chan []Job
}

func NewJobRegistry() (this *JobRegistry) {
  this = &amp;JobRegistry{make(chan JobRegistrySubmitRequest, 10), make(chan JobRegistryListRequest, 10)}
    
  go func() {
    jobMap := make(map[string] Job)
        
    for {
        select {
        case sub := &lt;- this.submission:
            job := MakeJob(sub.request) // ....
                
            jobMap[job.Id] = job
            sub.response &lt;- job.Id
                
        case list := &lt;- this.listing:
                
            res := make([]Job, 0, 100)
            for _, v := range jobMap {
                res = append(res, v)
            }
            list.response &lt;- res
                
        }

        /// case somechannel....
     }
   }()
    
   return
}

Basically, I encapsulate each operation inside a struct, which carries
the parameters and a response channel.

Then I created helper methods for end users:

func (this *JobRegistry) List() ([]Job, os.Error) {
	res := make(chan []Job, 1)
	req := JobRegistryListRequest{res}
	this.listing &lt;- req
	return &lt;-res, nil // todo: handle errors like timeouts
}

I decided to use a channel for each type of request in order to be type safe.


The problem I see with this approach are:

  • A lot of boilerplate code and a lot of places to modify when some param/return type changes

  • Have to do weird things like create yet another wrapper struct in order to return errors from within the handler goroutine. (If I understood correctly there are no tuples, and no way to send multiple values in a channel, like multi-valued returns)

So, I'm wondering whether all this makes sense, or rather just get back to good old locks.

I'm sure that somebody will find some clever way out using channels.

答案1

得分: 1

我不完全确定我理解你的意思,但我会尽力回答。

您想要一个执行发送给它的作业的通用服务。您可能还希望作业可以序列化。

我们需要一个定义通用作业的接口。

type Job interface {
    Run()
    Serialize(io.Writer)
}

func ReadJob(r io.Reader) {...}

type JobManager struct {
    jobs map[int] Job
    jobs_c chan Job      
}

func NewJobManager (mgr *JobManager) {
    mgr := &JobManager{make(map[int]Job),make(chan Job,JOB_QUEUE_SIZE)}
    for {
        j,ok := <- jobs_c
        if !ok {break}
        go j.Run()
    }
}

type IntJob struct{...}
func (job *IntJob) GetOutChan() chan int {...}
func (job *IntJob) Run() {...}
func (job *IntJob) Serialize(o io.Writer) {...}

代码量更少,而且大致上同样有用。

关于使用辅助流来发出错误信号,您可以始终使用一个辅助函数。

type IntChanWithErr struct {
    c chan int
    errc chan os.Error
}
func (ch *IntChanWithErr) Next() (v int,err os.Error) {
    select {
        case v := <- ch.c // 不处理关闭的通道
        case err := <- ch.errc
    }
    return
}
英文:

I'm not entirely sure I understand you, but I'll try answering never the less.

You want a generic service that executes jobs sent to it. You also might want the jobs to be serializable.

What we need is an interface that would define a generic job.

type Job interface {
    Run()
    Serialize(io.Writer)
}

func ReadJob(r io.Reader) {...}

type JobManager struct {
    jobs map[int] Job
    jobs_c chan Job      
}

func NewJobManager (mgr *JobManager) {
    mgr := &amp;JobManager{make(map[int]Job),make(chan Job,JOB_QUEUE_SIZE)}
    for {
        j,ok := &lt;- jobs_c
        if !ok {break}
        go j.Run()
    }
}

type IntJob struct{...}
func (job *IntJob) GetOutChan() chan int {...}
func (job *IntJob) Run() {...}
func (job *IntJob) Serialize(o io.Writer) {...}

Much less code, and roughly as useful.

About signaling errors with an axillary stream, you can always use a helper function.

type IntChanWithErr struct {
    c chan int
    errc chan os.Error
}
func (ch *IntChanWithErr) Next() (v int,err os.Error) {
    select {
        case v := &lt;- ch.c // not handling closed channel
        case err := &lt;- ch.errc
    }
    return
}

huangapple
  • 本文由 发表于 2011年5月17日 02:14:12
  • 转载请务必保留本文链接:https://go.coder-hub.com/6021553.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定