Hi John, I don't know what firm realtime means. I did look at GO's GC a bit. I'm not the expert in this, others in my company are.
On the question of realtime thread priorities, that is a requirement, as is priority inheritance. For hard realtime systems, you want essentially "unfair" scheduling for the realtime threads. Probably significant work, but we do have the advantage of almost 2 decades experience with hard realtime GCs. I'm trying to gauge the market interest in doing this. I haven't seen a lot of response on it. David On Thursday, November 9, 2017 at 2:58:27 PM UTC-5, John Souvestre wrote: > > I occasionally see projects which have hard real-time requirements, so I’m > interested. > > > > I understand your concern with GC but you have looked at Go’s current GC? > I don’t know if its limits (max pause time, max overhead) are “hard” but > they are stated. The one which isn’t is latency due to stopping goroutines > since they aren’t exactly pre-emptible. But there’s been some talk about > addressing this. > > > > I would think that you would need to add priorities and perhaps fairness > guarantees to scheduling and synchronization methods. > > > > It certainly sounds like a lot of work! Perhaps firm real-time would be a > good first step? > > > > John > > John Souvestre - New Orleans LA > > > > *From:* golan...@googlegroups.com <javascript:> [mailto: > golan...@googlegroups.com <javascript:>] *On Behalf Of *David Beberman > *Sent:* 2017 November 09, Thu 05:59 > *To:* golang-nuts > *Subject:* [go-nuts] question about GO and realtime GC interest by the > user community > > > > Hi, > I asked this on the golang-dev list. They redirected me here. > We are a hard realtime JavaVM GC company. By hard realtime > we mean that the GC is preemptible, reentrant, non-blocking, non-pausing. > For multicore it is also parallel and concurrent. > Further for realtime we support priority inheritance for synchronization > primitives, and of course hard realtime thread priorities. > > GO's requirements for GC are slightly different. The concept > would be to add our hard RTGC to the GO runtime without > disrupting the language. > > My question is about the interest level in the GO user community. > We have developed and marketed hard realtime Java bytecode VM's > for 16+ years. > GO looks like the new kid on the block. Maybe it moves into > realtime use-cases, maybe it doesn't. > > Kind of doing an extremely informal poll here. > Open to any thoughts, comments. > > Thanks > David Beberman > Aicas GmbH > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
