• Как "наследовать метод" golang?

    @s_kozlov
    package main
    
    
    import "fmt"
    
    type AnimalIntf interface {
    	Walk() AnimalIntf
    	Say() AnimalIntf
    }
    
    type Animal struct {
    	animal    AnimalIntf
    	Name string
    }
    
    type Rabbit struct {
    	Animal
    }
    
    
    // Animal
    func NewAnimal(name string) *Animal {
    	animal := new(Animal)
    	animal.animal = animal
    	animal.Name = name
    	return animal
    }
    
    //Метод Walk у каждого свой
    func (this *Animal) Walk() AnimalIntf {
    	fmt.Println("I walk", this.Name)
    	return this.animal
    }
    
    //Метод Say общий
    func (this *Animal) Say() AnimalIntf {
    	fmt.Println("Im Animal and my Name is", this.Name)
    	return this.animal
    }
    
    
    // Rabbit
    func NewRabbit(name string) *Rabbit {
    	rabbit := new(Rabbit)
    	rabbit.animal = rabbit
    	rabbit.Name = name
    	return rabbit
    }
    
    //Метод Walk изменяется для Rabbit и работает корректно
    func (this *Rabbit) Walk() AnimalIntf {
    	this.Animal.Walk()
    	fmt.Println("...and Jump")
    	return this.animal
    }
    
    
    func main() {
    
    	animal := NewAnimal("Зверь")
    	animal.Walk().Say().Walk()
    
    	fmt.Println("\n---------------------\n")
    
    	rabbit := NewRabbit("Кроль")
    	rabbit.Walk().Say().Walk()
    
    }

    примерно так, как вариант
    вывод:
    I walk Зверь
    Im Animal and my Name is Зверь
    I walk Зверь
    
    ---------------------
    
    I walk Кроль
    ...and Jump
    Im Animal and my Name is Кроль
    I walk Кроль
    ...and Jump
    Ответ написан
    Комментировать
  • В чем проблема отправки сигнала дочернему процессу?

    Tyranron
    @Tyranron
    Извините за прямоту, но проблема в недостаточном знании Вами матчасти.
    Что почитать по теме: Zombie process, а также Docker and the PID 1 zombie reaping problem.

    А теперь ближе к Вашему примеру.
    Cуть: и SITERM'ом, и SIGKILL'ом Вы child процесс успешно убиваете, после чего он превращается в зомби-процесс, то есть все еще висит в памяти под своим PID ожидая reaping (системного вызова wait() от parent процесса). После завершения parent процесса наш зомби-child усыновляется init процессом, который его и reap'ит.
    Если запустить Ваши программы в том виде, котором Вы их запостили, и во время тиканья написать ps, то увидим следующую картину:
    459 ttys000    0:00.03 -bash
    498 ttys000    0:00.00 ./parent
    499 ttys000    0:00.00 (child)
    То, что child указан в скобках, как раз и означает, что процесс был остановлен (то есть он совершил системный вызов exit()) и ожидает reaping'а (когда результат exit()'а прочтут wait()'ом).
    Если перед посылкой child'у добавитьtime.Sleep(10 * time.Second) и сразу после вывода child'овского PID'а набрать глянуть что творится в процессах, то увидим такую картину:
    459 ttys000    0:00.04 -bash
    510 ttys000    0:00.00 ./parent
    511 ttys000    0:00.00 ./child
    Сравните с тем как он отображается в процессах после того, как был убит.
    А если мы после посылки сигнала child'у добавимcmd.Process.Wait(), то Ваш цикл ticker'а все равно, возможно, еще будет крутится, если в системе появился новый процесс с таким PID'ом, но если при этом заглянуть в ps, то увидим, что нашего child'а уже нет совсем:
    459 ttys000    0:00.05 -bash
    536 ttys000    0:00.01 ./parent

    Кстати, о волшебной силе Process.Wait() пишется прямо в его доке.
    Ответ написан
    1 комментарий
  • Как бы вы сделали проверку на запуск второго экземпляра программы?

    Tyranron
    @Tyranron
    Мне не нравится 3й вариант, так как он не решает задачу целиком. Порт, который слушать - это больше конфигурационный параметр, значит надо задумываться уже, ничего ли страшного не случится при смене порта и рестарте (обычно не должно, но раз на раз не приходится). А что, если демону и вовсе не нужно слушать какой-либо порт? Не универсальненько.

    Увы, кросс-платформенного решения "из коробки" нет, да. Я когда стряпал свою поделку, то меня интересовали только *nix-like платформы, мне хватило старого хорошего PID-файла с syscall.Flock. То, что видел в других решениях, более кросс-платформенных, - люди заморачивались на platform specific код, для Windows они использовали регистрацию процесса в виде сервиса. Обернуть это дело в отдельный пакет с единым интерфейсом и platform specific компиляцией совсем не сложно в случае с Go. Для работы с сервисами Windows есть замечательный, пусть и не входящий в стандартную либу, но все же официальный пакет golang.org/x/sys/windows/svc, и костылить на чистых syscall'ах даже не нужно.
    Также загляните в этот тред, там как раз про решение для Windows в виде semaphore/mutex аналогично тому, что указал Владимир Мартьянов в комментарии к Вашему вопросу и тому, что Вы указали 2м пунктом.
    Ответ написан
    Комментировать
  • Какие агрегаторы ссылок с умными западными мыслями по поводу веб-разработки вы ещё знаете?

    websanya
    @websanya
    Фронтенд разработчик, подкастер
    В разных пабликах на вк можно оперативно получать информацию, например наш uwebdesign. Кроме того, что ты написал есть еще webdesigner news, очень похож на reddit. Ну и куча дайджестов по конкретным тематикам. Какие языки интересуют?
    Ответ написан
    2 комментария
  • Linux: большое количество файлов в папке - это сколько?

    javenue
    @javenue
    По собственному опыту:
    10 тысяч — вполне нормальное число.
    50 тысяч и больше — стоит подумать о подпапках и иерархичности папок / документов.
    Ответ написан
    Комментировать