Показаны сообщения с ярлыком freebsd. Показать все сообщения
Показаны сообщения с ярлыком freebsd. Показать все сообщения

среда, 23 июня 2010 г.

Pthread's hint !

Заметка эта появилась благодаря курсу "Многопоточное программирование с использованием POSIX Threads" на сайте Решил просмотреть курс , думал не найду ничего нового для себя - и вот нашел :)

В заметке речь пойдет о использовании pthread_exit (), вернее о том, что ведет эта ф-я на разных платформах по разному !

Пример :

#include  
#include  
#include  

class TestClass { 
  public:    
  int value; 
  TestClass(int parameter) { 
    std::cout << "Constructed " << parameter << "\n"; 
    value=parameter; 
  } 
  ~TestClass() { 
    std::cout << "destructed " << value << "\n"; 
  } 
}; 

extern "C" { 
  void *body_forexit(void * param) { 
    TestClass a(1); 
    sleep(1); 
    pthread_exit((void *)a.value); 
    return (void *)a.value; 
  } 

  void *body_forreturn(void * param) { 
    TestClass b(2); 
    sleep(2); 
    return (void *)b.value; 
  } 
} // extern "C" 

int main() { 
  pthread_t thread1, thread2; 
  
  pthread_create(&thread1, NULL, body_forexit, NULL); 
  pthread_detach(thread1); 
  pthread_create(&thread2, NULL, body_forreturn, NULL); 
  pthread_detach(thread2); 
  pthread_exit(NULL); 
  return 0; 
} 

итог запуска скомпилированной проги на разных платформах :
Linux desktop 2.6.28-15-generic #49-Ubuntu SMP Tue :
andrey@desktop:~/dev/threads$ ./a.out Constructed 1 Constructed 2 destructed 1 destructed 2
7.0-RELEASE FreeBSD :
Constructed Constructed 1 2 destructed 2

И того - на фре7 при использовании pthread_exit НЕ ВЫЗЫВАЮТСЯ ДЕСТРУКТОРЫ !!!!!!!
А в линуксе ВЫЗЫВАЮТСЯ !!!
Имхо правильнее использовать ретурн , чтоб небыло неожиданности :)

вторник, 22 июня 2010 г.

настройка ssmtp

всегда забываю прописать :

/etc/mail/mailer.conf

sendmail /usr/local/sbin/ssmtp
send-mail /usr/local/sbin/ssmtp
mailq /usr/local/sbin/ssmtp
newaliases /usr/local/sbin/ssmtp
hoststat /usr/bin/true
purgestat /usr/bin/true

Thread's in FreeBSD

libkse :
kernel support for user threads

libc_r :
the old user space thread library.

libthr ( pthread ) :
library provides a 1:1 implementation of the pthread(3) library interfaces for application threading. It has been optimized for use by applications expecting system scope thread semantics, and can provide significant performance improvements compared to N:M Threading Library (libkse, -lkse).

pth :
GNU Portable Threads

linuxthreads:
/usr/ports/devel/linuxthreads
LinuxThreads is an POSIX pthreads implementation using "kernel threads". In this FreeBSD port, a kernel thread is started using rfork (whereas in the original Linux implementation a kernel thread is started using the Linux clone call).

вторник, 9 марта 2010 г.

Очередность поиска IP адреса

Очередность поиска IP адреса "резолвером" можно регулировать через
/etc/host.conf ( если это FreeBSD до 5.0 версии ) :

order
Данное ключевое слово задает метод, с помощью которого будет осуществляться поиск адреса узла. За этим словом должно следовать одно или несколько названий методов, разделенных запятыми. Допустимы следующие названия методов: bind, hosts и nis.


либо же через /etc/nsswitch.conf

hosts: dns files nis


пятница, 5 марта 2010 г.

Serial port in FreeBSD part 2

Re: /dev/cuad0: Device busy

Andrew Kolchoogin
Mon, 04 Feb 2008 05:52:14 -0800

> > > Personally, I never understood the concept of "dial-in" and "call-out" 
> > > devices on FreeBSD.  I ran BBS software for years on both Apple II 
> > > hardware and PC hardware; there was no distinction between such devices. 
> > > A serial port is a serial port.  Chances are I'm not understanding why 
> > > there's a distinction, but there doesn't appear to be any explanation of 
> > > why there's a distinction within manpages or the handbook... 
> > The distinction exists to allow an application to wait on the "dial-in" 
> > port for incoming calls and another application to make outgoing call 
> > mean time using the same port as "call-out" while the port is idle. 
> And once there is a incoming call block out going calls until 
> the incoming call completes.
    And for now one must forget existance of such devices and use /dev/ttyd* for both incoming and outgoing calls.      Long history is the following: terminal devices under UNIX have changed its semantics quite a long time ago. Historically, there are a pair of devices, one was for dial-in, and another -- for dial-out. This absurd was created because of absence of non-blocking open()'s -- O_NONBLOCK simply doesn't work for open()'s of devices. As such, historical getty implementation opens port in blocking mode and blocks until carrier is detected on terminal line. Kernel doesn't allow multiple simultaneous opens of /dev/tty* in blocking mode to prevent multiple applications from accessing serial port simultaneously -- as such, if we want to make outgoing call, we ought to have 'some another' device physically attached to the same serial port, so, /dev/cua* exist.      For now, there are virtually no software that relates on this behaviour -- POSIX tty locking semantics mandate us to check lock files in well-known system-wide directory -- /var/spool/lock in FreeBSD. Kernel allows opens of /dev/tty* in non-blocking mode many times, as such, no special 'dial-out' device needs to make outgoing call.      It is clear that _all_ applications communicating with serial port use one semantics -- historical UNIX or POSIX. One can not use system /usr/libexec/getty with POSIX-compatible software because it opens /dev/tty* in blocking mode. Use comms/mgetty+sendfax mgetty instead -- to be precise, mgetty also can be used with UNIX tty semantics (see description of configuration keyword "blocking"), but just don't do it. ;)
Взято из :
http://www.mail-archive.com/freebsd-stable@freebsd.org/msg93890.html


Serial port in FreeBSD

The third serial port, sio2 (see sio(4), known as COM3 in DOS), is on /dev/cuaa2 for dial-out devices, and on /dev/ttyd2 for dial-in devices. What is the difference between these two classes of devices?

You use ttydX for dial-ins. When opening /dev/ttydX in blocking mode, a process will wait for the corresponding cuaaX device to become inactive, and then wait for the carrier detect line to go active. When you open the cuaaX device, it makes sure the serial port is not already in use by the ttydX device. If the port is available, it ``steals'' it from the ttydX device. Also, the cuaaX device does not care about carrier detect. With this scheme and an auto-answer modem, you can have remote users log in and you can still dial out with the same modem and the system will take care of all the conflicts.


понедельник, 21 сентября 2009 г.

Обуздал kqueue :)



int _init ( )
{
_open ( );

if ( ( _kq = kqueue ( ) ) == -1 )
{
printf ( "C'ant kreate kqueue ......\n" );
_close ( );
return -1;
}

printf ( "Kqueue created !\n" );


EV_SET( &_ke, _port, EVFILT_READ, EV_ADD | EV_ENABLE | EV_CLEAR , NOTE_WRITE, 0, 0);

if ( kevent( _kq, &_ke, 1, NULL, 0, NULL) == -1 )
{
printf ( "C'ant register kevent ......\n" );
_close ( );
return -2;
}




return rv;
}


int _readDelayed ( char * buf, int len, timeval timeoutv )
{


timespec timeout = { tv_sec, tv_usec };

bzero ( &_ke, sizeof ( _ke ) );

int rez = kevent ( _kq, NULL, 0, &_ke, 1, &timeout );
if ( rez <= 0 ) return -3;

for ( int n = 0 ; n < rez; n++ )
{
if ( _ke.flags & EV_ERROR )
{
printf ( "error in event......\n" );
return -1;
}
if ( _ke.filter == EVFILT_READ )
{
int rcv = _read ( buf, len );
return rcv;
}
else
{
printf ( "strange behavior ......\n" );

}
}

return -1;
}


четверг, 3 сентября 2009 г.

Установка фри 7.0 по сети

После долги мучений :) мне это удалось !!!!

Итак на сервере :

была сделана папочка /usr/tftpboot в которую сброшено все содержимое 3-х дисков ( сначала была попытка сделать линк на корень типа /tftpboot , но нфс не дружит с линками :) )

итак правим
/etc/exports :

/usr/tftpboot -alldirs -maproot=0 -network 0.0.0.0 -mask 0.0.0.0

потом правим /etc/inetd.conf

tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /usr/tftpboot

далее в /usr/local/dhcp.conf добавляем хост , которому будем выдавать ИП

host freetest {

hardware ethernet 00:0c:29:f5:dd:70; # MAC - адрес тачки которой мы дадим :)
fixed-address 10.18.201.84; #Этот адрес мы выдаем
next-server 10.18.201.80; # Сервер
filename "boot/pxeboot";
option root-path "10.18.201.80:/usr/tftpboot"

}


в /usr/tftpboot/boot/loader.conf должно быть :

mfsroot_load="YES"
mfsroot_type="mfs_root"
mfsroot_name="/boot/mfsroot"
vfs.root.mountfrom="ufs:/dev/md0c"


далее пускаем rpcbind, nfsd, mountd -r , dhcpd и наслаждаемся ))))

поправочка :

Workaround for a bug in mfs_root

I've confirmed that there is in fact a bug in the mfs_root loading mechanism. It's likely been there for a very long time, since a couple other guides state that after rebuilding their mfsroot, if they re-gzip'd the mfsroot image, their machines would reboot.

On our servers, something bizarre happens: the kernel appears to get reloaded, all of the environment variables are lost (which means serial console is lost), and then there's some nastiness on the console about how it can't find "kernel", and some weird Device ID 0xffffffff error. I'd have to take a photo of the monitor to provide additional details, but regardless, this problem is easily reproducible. I filed a PR for this problem, kern/120127, but as of this writing not a single developer has bothered to look into it. I'm willing to bet this bug has bitten the EtherBoot folks as well.

The workaround is simple: remove the gzip compression on the mfsroot.gz image, and everything should work:

# gzip -d /path_to_distr/boot/mfsroot


http://jdc.parodius.com/freebsd/pxeboot_serial_install.html

MySQL и UTF-8

Надо было настроить mysql на utf-8
помогло вот єто :
[mysqld]

default-character-set=utf8
character-set-server=utf8
collation-server=utf8_general_ci
init-connect="SET NAMES utf8"
skip-character-set-clienthandshake=yes



[mysqldump]

default-character-set=utf8


и все заработало ! :)