It was kind of random, sometimes SIGBUS, next time SIGEGV, it needs
another round of testing. The goal was just simple replace with and see
if aio_write may work, looks like it does not.
I checked samba and squid, they use some kind of high level wrappers
around AIO, most of the time their own re-implemenation using threads.
Will it be more generic way just to set upper limit, if we see that
upload exceeds that limit, pass control to conn thread and let it finish
reading, this way, even spooling to file will work, because each upload
conn thread will use their own file and will not hold driver thread.
Every conn thread calls NsGetRequest which uses SockRead, so somewhere
in the driver.c we can check for max upload limit and mark Sock for conn
queueing, so NsGetRequest will finish upload.
Yes, too many connections will take all threads but that's how it works
anyway, nsd can be configured with maxconn that corresponds to any
particular system/load.
Zoran Vasiljevic wrote:
Am 02.01.2006 um 19:13 schrieb Vlad Seryakov:
I did very simple test, replaced write with aio_write and at the end
checked aio_error/aio_return, they all returned 0 so mmap should work
because file is synced. when i was doing aio_write i used aio_offset,
so each aio_write would put data into separate region on the file.
Unfortunately i removed modified driver.c by accident, so i will have
to do it again but something is not right in simply replacing write
with aio_write and mmap. Without mmap, GetForm will have to read the
file manually and parse it, it makes it more complicated and still,
if writes are not complete we may get SIGBUS again.
The problem i see here i cannot be sure that all writes are
completed, aio_error/aio_return are used to check only one last
operation, not the batch of writes.
Hmmm... that means that before writing the next chunk, you should check
the
status of the last and skip if still not written?
OTOH, how come you get SIGBUS? And where? Normally this might be only
if you mmap the file as some structure, not char array?
Zoran
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
naviserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
