Re: CVS commit: src/usr.bin/pkill
In article <20404.1353628...@splode.eterna.com.au>, matthew green wrote: > >> | this seems like a fairly big semantic change to me. >> | >> | could you change it to take a new option to look in argv[0] instead >> | of p_comm? p_comm is not changeable by the user. >> >> You could already do this with -f. The point was to make the default case >> behave intuitively. Adding an option is against that. I could add backwards >> compatibility by checking both, but I think that in the long term this will >> be dangerous and confusing (since you might end up killing more than you >> thought you would...) > >but again, it's a semantic change. > >the old system was a constant identifier that never changed over >the life of the process (it may not be unique.) the argument list >is under the control of the process itself, so what's being matched >here is a different thing. > >i guess i've known about the 16-byte limitation and understood it, >but since it was p_comm it was a reasonable limit. now there is >no way to match against p_comm at all, right? No there is not; and should we add it, we should consider truncating the provided string to 16 characters... christos
re: CVS commit: src/usr.bin/pkill
> | this seems like a fairly big semantic change to me. > | > | could you change it to take a new option to look in argv[0] instead > | of p_comm? p_comm is not changeable by the user. > > You could already do this with -f. The point was to make the default case > behave intuitively. Adding an option is against that. I could add backwards > compatibility by checking both, but I think that in the long term this will > be dangerous and confusing (since you might end up killing more than you > thought you would...) but again, it's a semantic change. the old system was a constant identifier that never changed over the life of the process (it may not be unique.) the argument list is under the control of the process itself, so what's being matched here is a different thing. i guess i've known about the 16-byte limitation and understood it, but since it was p_comm it was a reasonable limit. now there is no way to match against p_comm at all, right? .mrg.
Re: CVS commit: src/lib/libpthread
On Nov 22, 9:14am, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: CVS commit: src/lib/libpthread | On Wed, Nov 21, 2012 at 07:35:29PM -0500, Christos Zoulas wrote: | > Ok, that's simple to change. But where is the documentation for how this | > is supposed to work, so I can put a cross-reference to it. | | http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_key_delete.html | | It is the responsibility of the application to free any application | storage or perform any cleanup actions for data structures related to | the deleted key or associated thread-specific data in any threads; this | cleanup can be done either before or after pthread_key_delete() is | called. Any attempt to use key following the call to | pthread_key_delete() results in undefined behavior. | | and later in the Rationale: | | No such cleanup is done by pthread_key_delete(). In particular, | destructor functions are not called. Fixed, thanks! christos
Re: CVS commit: src/lib/libpthread
On Wed, Nov 21, 2012 at 07:35:29PM -0500, Christos Zoulas wrote: > Ok, that's simple to change. But where is the documentation for how this > is supposed to work, so I can put a cross-reference to it. http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_key_delete.html It is the responsibility of the application to free any application storage or perform any cleanup actions for data structures related to the deleted key or associated thread-specific data in any threads; this cleanup can be done either before or after pthread_key_delete() is called. Any attempt to use key following the call to pthread_key_delete() results in undefined behavior. and later in the Rationale: No such cleanup is done by pthread_key_delete(). In particular, destructor functions are not called. Martin
