This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 26 Jan 2016 13:40, Szabolcs Nagy wrote: > On 26/01/16 13:23, Yury Gribov wrote: > > On 01/26/2016 04:14 PM, Florian Weimer wrote: > >> On 01/26/2016 01:44 PM, Szabolcs Nagy wrote: > >>> On 26/01/16 00:25, Joern Engel wrote: > >>>> With signals we can reenter the thread-cache. Protect against that with > >>>> a lock. Will almost never happen in practice, it took the company five > >>>> years to reproduce a similar race in the existing malloc. But easy to > >>>> trigger with a targeted test. > >>> > >>> why do you try to make malloc as-safe? > >>> > >>> isn't it better to fix malloc usage in signal handlers? > >> > >> We have functionality like dprintf, syslog, backtrace, C++ thread-local > >> object access which might be used from signal handlers, but which can > >> call malloc. > > > > Right. One can argue that this is an error and someone should go fix the code but in my experience most > > real-world signal handlers have these problems and noone is going to rewrite them any time soon. > > > > it is easy to write non-conforming code, but that > does not mean the libc should try to make it work. and that has a real cost for real time code, as well as adding real overhead to hot paths. we spend so much time on trying to get lock less code, just to re-add overhead by calling into the kernel ? > in this case signals should be blocked whenever the > library is entered through non-as-safe api calls. > that has a significant cost for portable code. err, this statement makes no sense. if you were writing portable code, you wouldn't be using malloc or other non-as safe code in the signal handler in the first place. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |