From mboxrd@z Thu Jan 1 00:00:00 1970 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <6283119B-D436-4027-9F0B-1E0ADE07763B@bitblocks.com> Content-Transfer-Encoding: quoted-printable From: Bakul Shah Date: Mon, 3 Jun 2013 10:33:21 -0700 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Go and 21-bit runes (and a bit of Go status) Topicbox-Message-UUID: 624f53e2-ead8-11e9-9d60-3106f5b1d025 On Jun 3, 2013, at 10:07 AM, erik quanstrom wrote: > On Mon Jun 3 13:05:07 EDT 2013, lucio@proxima.alt.za wrote: >>> if by intent, you mean that go is using xmm registers as if they were >>> general purpose registers, then the solution is to stop doing that. >>> and there's such a patch already. >>=20 >> No, Go's intent is to minimise runtime surprises. It is possible to >> define signal (calling them notes does not change their nature) >> handlers and nothing in the Go specifications compels the user not to >> use floating point instructions in such handlers. It would also not >> be possible to enforce such restrictions in known implementations of >=20 > signals are not compatable with notes. i don't think this > can be truely portable code anyway. Not compatible but signals have similar restrictions. A signal may be delive= red at any time where any state maintained in usercode may be inconsistent. I= n particular use of any non-reentrant function can cause trouble. Used to be= , you don't use floating pt. in signal handlers as that would require the ke= rnel to save more state, slowing down signal delivery, or it could cause ano= ther trap where the kernel can do the lazy saving trick. Most mallocs are no= n reentrant as well and you shouldn't use malloc in a handler. All in all a v= ery restricted environment.=20=