Re: [GENERAL] fork() bad
От | Richi Plana |
---|---|
Тема | Re: [GENERAL] fork() bad |
Дата | |
Msg-id | Pine.LNX.4.04.9903230025410.23588-100000@jaguar.mozcom.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] fork() bad (Herouth Maoz <herouth@oumail.openu.ac.il>) |
Ответы |
Re: [GENERAL] fork() bad
|
Список | pgsql-general |
Hi, Herouth. On Mon, 22 Mar 1999, Herouth Maoz wrote: |o| > As some of you may know, I'm hacking Ascend RADIUS 2.01 to look up a |o| > PostgreSQL database for authentication and log to PG for accounting. |o| > Normally, RADIUS fork()s once for Accounting and fork()s for each |o| > Authentication request. That's a lot of fork()ing and establishing |o| > connections to the backend. It's slow, but it's better than junking |o| > whatever code I've written so far. |o| > |o| > If anyone can give a better suggestion, I'm all ears. Also, if anyone |o| > wants the code when it's done, try asking. ;^) |o| |o| Why don't you try to synchronize access to the connection between the |o| various processes? You know, lock it in an exclusive lock, on an |o| inter-process basis, such that when one process accesses it, the others |o| have to wait. Or you can have a few connections open, so that the |o| bottleneck is wider. You know, like you would treat any shared object in an |o| inter-process environment? It kinda defeats the purpose of allowing RADIUS to fork() if I do locking. I've no benchmarks to prove it, but if I allow it to execute one process at a time via locking, that would probably slow the other processes down. (ie. Should the waiting process block? If so, when will it try again? Are the overheads to establishin a connection really that big?) L L Richi Plana 8^) ,-,-. ,-,-. ,-,-. ,-,-. ,- LL LL Systems Administrator / / \ \ / / \ \ / / \ \ / / \ \ / / LLLLL Mosaic Communications, Inc. \ \ / / \ \ / / \ \ / / \ \ / / LLLLL mailto:richip@mozcom.com `-'-' `-'-' `-'-' `-'-' ------------------------------------------------------------------------ P G P Key available at http://www2.mozcom.com/~richip/richip.asc Tired of Spam? Join this CAUCE! http://www.cauce.org/
В списке pgsql-general по дате отправления: