On 02/03/2010 10:02 PM, Pete Zaitcev wrote:
As it turned out, event_loopbreak() does not awaken the thread that
exectutes event_dispatch(), but our code expected that it would.
One easily noticeable effect was that there was a noticeable delay
between the state transition to DB master and listeni
As it turned out, event_loopbreak() does not awaken the thread that
exectutes event_dispatch(), but our code expected that it would.
One easily noticeable effect was that there was a noticeable delay
between the state transition to DB master and listening on sockets.
I knew the mysterious delay exi
On Wed, Feb 3, 2010 at 2:27 PM, Jeff Garzik wrote:
> On 02/03/2010 08:45 AM, Colin McCabe wrote:
>>
>> When we create a static buffer for an inode name, and treat it like a
>> null-terminated string, it needs to be of length CLD_INODE_NAME_MAX + 1 so
>> that it can hold the NULL-terminator.
>>
>>
On 01/20/2010 05:56 PM, Pete Zaitcev wrote:
Is there a way to cancel an outstanding lock request? How? You seem
to think that there's no problem.
Actually I think an cmo_close on a handle that has outstanding
requests of any kind should drop them, so I was incorrect about
killing the session bei
On 02/03/2010 08:45 AM, Colin McCabe wrote:
When we create a static buffer for an inode name, and treat it like a
null-terminated string, it needs to be of length CLD_INODE_NAME_MAX + 1 so
that it can hold the NULL-terminator.
In cldc_del and cldc_open, we should check that the user-submitted in
Get rid of CLD_MAX_PKT_MSG. It only existed so that we could use static arrays
in a few places.
Create CLD_MAX_PAYLOAD_SZ to represent the maximum size of a message that the
API user can GET or PUT. Reducing this constant could break users who
relied on the old maximum data size, so we should try
v2: one part of this patch was originally accidentally mixed into patch 2
When we create a static buffer for an inode name, and treat it like a
null-terminated string, it needs to be of length CLD_INODE_NAME_MAX + 1 so
that it can hold the NULL-terminator.
In cldc_del and cldc_open, we should che
On Tue, Feb 2, 2010 at 10:35 PM, Jeff Garzik wrote:
> On 01/29/2010 08:01 PM, Colin McCabe wrote:
>>
>> That seems reasonable. All of those functions could be looked at as
>> "common."
>>
>> The intention was to group together a bunch of functions that were
>> useful for packet formatting. Althoug
Get rid of CLD_MAX_PKT_MSG. It only existed so that we could use static arrays
in a few places.
Create CLD_MAX_PAYLOAD_SZ to represent the maximum size of a message that the
API user can GET or PUT. Reducing this constant could break users who
relied on the old maximum data size, so we should try
When we create a static buffer for an inode name, and treat it like a
null-terminated string, it needs to be of length CLD_INODE_NAME_MAX + 1 so
that it can hold the NULL-terminator.
In cldc_del and cldc_open, we should check that the user-submitted inode name
is less than or equal to CLD_INODE_NA
10 matches
Mail list logo
