On 05/04/2014 06:34 PM, Christoph Hellwig wrote:
> On Sun, May 04, 2014 at 03:44:15PM +0800, Junxiao Bi wrote:
>> Sending a SIGKILL signal to child thread will terminate the whole process,
>> xfs_copy will return an error value 137. This cause confuse for script to
>> know whether the copy successes.
>>
>> Calling exit() in main thread can terminate the whole process and return the
>> right value.
> Looks generally good to me, but the changelog should have some more
> details:
Yes, will update.
>
>> if (buf->length > buf->size) {
>> do_warn(_("assert error: buf->length = %d, buf->size = %d\n"),
>> buf->length, buf->size);
>> - killall();
>> - abort();
>> + exit(1);
> You're replacing the killall with an exit here and removing the abort()
> call. I can see arguments for keeping either the abort or exit, but please
> document why you did in the patch description. If the exit was
> intentional should we return a different value for an assertation
> failure?
I think exit() is more clear than killall()+abort(). And xfs_copy uses
exit(1) to exit before creating threads.
I think 1 is OK, since all values except 0 means xfs_copy fail.
>
>> - killall();
>> - pthread_exit(NULL);
>> - /*NOTREACHED*/
>> - return 0;
>> +
>> + exit(0);
> You're also replacing the return 0 from main with an exit which
> seem superflous.
Yes, return 0 is OK. Will update the patch.
>
> Btw, I think the reason for this cruft is that xfs_copy was originally
> written using the IRIX sproc interface, and the port to pthreads didn't
> remove this gem:
Thanks for point the reason.
Thanks,
Junxiao.
>
> http://marc.info/?l=linux-xfs&m=99535721110020&w=2
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
